केस स्टडी
आपकी मुख्य लिस्ट स्क्रीन अचानक क्यों खुलना बंद हो जाती है
एक क्लाइंट की मुख्य लिस्ट खुलना बंद हो गई, जबकि बाकी हर पेज चल रहा था। वजह एक ऐसा रिकॉर्ड था जो बाकी सबसे कहीं बड़ा हो गया था, और वही गड़बड़ी एक background task में चुपचाप फेल हो रही थी।
मुख्य बातें
- जो लिस्ट अचानक खुलना बंद कर दे, उसके पीछे अक्सर एक बड़ा रिकॉर्ड होता है, किसी का किया हुआ बदलाव नहीं।
- Database rows को पूरा-पूरा क्रम में लगाता है, इसलिए क्रम के लिए तय memory से बड़ा एक रिकॉर्ड पूरा पेज फेल कर देता है।
- लिस्ट को सिर्फ वही लोड करना चाहिए जो वह दिखाती है; लंबे documents और files उस पेज के होते हैं जो एक आइटम खोलता है।
- यही वजह अक्सर किसी scheduled background task में चुपचाप फेल हो रही होती है, जिसकी alert किसी को नहीं मिलती।
- Memory की सीमा बढ़ाना समस्या को हटाने के बजाय अगले, और बड़े रिकॉर्ड तक खिसका देता है।
एक क्लाइंट की टीम ने अपने internal system में मुख्य लिस्ट खोली और पेज पर error दिखा। उस स्क्रीन को किसी ने बदला नहीं था, और बाकी हर पेज चल रहा था। वजह एक ही रिकॉर्ड था जो बाकी सबसे कहीं ज़्यादा बड़ा हो गया था।
जो लिस्ट नहीं खुलती, वह टीम का कितना काम रोकती है
मुख्य लिस्ट वही जगह है जहाँ टीम अपना काम ढूँढती है, खोलती है और पूरा करती है, इसलिए जब वह खुलना बंद हो जाए तो पूरी टीम के साथ रुक जाती है। इस क्लाइंट के लिए उस लिस्ट में वही आइटम हैं जिन पर टीम काम करती है, सबसे नए सबसे ऊपर। जिस पेज को वे बिना सोचे इस्तेमाल करते थे, अब उस पर error के सिवा कुछ नहीं दिख रहा था, जबकि बाकी हर स्क्रीन सामान्य चल रही थी।
यही मेल, एक स्क्रीन खराब और कुछ भी न बदला होना, इन गड़बड़ियों को रहस्यमय बना देता है। हमारे अनुभव में ये लौटकर आती हैं, क्योंकि गड़बड़ी डेटा के साथ बढ़ती है, किसी इंसान के किए से नहीं। यही लक्षण किसी भी बढ़ते system में दिखता है: किसी internal tool की लिस्ट टूट जाना, किसी CRM की लिस्ट न खुलना, कोई ऐसी स्क्रीन जिस पर टीम पूरा दिन निर्भर है।
admin लिस्ट पेज के न खुलने की वजह अक्सर एक बड़ा रिकॉर्ड क्यों होती है
सबसे नए आइटम पहले दिखाने के लिए database rows को क्रम में लगाता है, और वह उन्हें पूरा-पूरा लगाता है। Database वह भंडार है जहाँ internal system अपने रिकॉर्ड रखता है, और जब भी आप रिकॉर्ड किसी खास क्रम में माँगते हैं, तब क्रम में लगाना होता है। इस तरह के क्रम में लगाने के लिए database काम की जगह के तौर पर एक तय मात्रा में memory अलग रखता है, और शुरू करने से पहले वह हर row को तौलता नहीं: हर row पूरी की पूरी, जो कुछ उसमें है सबके साथ, क्रम में लगाने में जाती है। उस सीमा से बड़ी एक row पूरी लिस्ट को फेल कर देती है, चाहे बाकी कितनी भी छोटी हों।
इसीलिए रिकॉर्ड के आकार का बढ़ना भी उतना ही पक्का काम बिगाड़ता है जितना उनकी संख्या का बढ़ना। रिकॉर्ड जोड़ने से लिस्ट धीमी होती है; एक असामान्य रूप से बड़ा रिकॉर्ड जोड़ने से वह खुलना ही बंद हो सकती है।
हमारे engineer को क्या मिला
Error database से आ रहा था और कह रहा था कि क्रम में लगाने के लिए उसकी memory खत्म हो गई। चूँकि सबसे नए आइटम पहले दिख रहे थे, rows क्रम में लग रही थीं, और हर row अपने साथ title और date के अलावा एक भारी field भी ले जा रही थी। वह field लंबे टेक्स्ट का एक बड़ा हिस्सा था जो लिस्ट कभी दिखाती ही नहीं थी।
ये fields आमतौर पर छोटे होते हैं। टीम ने हाल ही में एक नई तरह के आइटम बनाना शुरू किया था, और उनमें से एक के साथ पहले से कहीं लंबा field आ गया। इस तरह के क्रम में लगाने के लिए database एक तय मात्रा में काम की memory अलग रखता है, और वह एक row अब उसमें नहीं समाई, इसलिए पूरी लिस्ट फेल हो गई। Database की memory बढ़ाना सिर्फ सीमा को अगले, और बड़े रिकॉर्ड तक खिसका देता।
मोड़ एक सीधे सवाल से आया: क्या लिस्ट को वह field चाहिए भी? वह title, state और date दिखाती है, बस इतना ही।
वही error कहीं और खोजने से बाकी कहानी भी सामने आई। वही गड़बड़ी एक background task में चुपचाप फेल हो रही थी, ऐसा काम जो timer पर चलता है और जिसे कोई देखता नहीं। इसे किसी ने देखा ही नहीं था। टीम को सिर्फ अपने सामने वाली स्क्रीन का पता था।
हमने क्या बदला
हमने लिस्ट को हर आइटम भारी field के बिना पढ़ने दिया, इसलिए पेज सिर्फ title, state और date लोड करता है। वह field तब पढ़ा जाता है जब कोई उस आइटम को खोलता है, और सिर्फ तभी। हमने एक index भी जोड़ा, एक lookup ढाँचा जो आइटम को उनके आखिरी बदलाव के क्रम में रखता है, ताकि सबसे नया पहले दिखाने के लिए क्रम में लगाने की ज़रूरत ही न पड़े।
थोड़ी देर बाद, यही सोच पूरे system पर लागू हुई: जब तक खास fields न माँगी जाएँ, इन आइटम की request अब भारी field को default से बाहर रखती है, background task की requests भी। एक आइटम खोलने पर field पूरा पढ़ा जाता है। एक नई स्वचालित जाँच अब पकड़ लेती है अगर लिस्ट या task फिर से वह field माँगने लगे।
अब business के पास क्या है
बदलाव उसी दिन क्लाइंट के system पर लाइव हो गए। लिस्ट फिर खुलती है और background task फिर चलता है। किसी भी लंबाई का आइटम अब इनमें से किसी को नहीं तोड़ सकता, और एक आइटम खोलना पहले की तरह काम करता है।
आप खुद क्या जाँच सकते हैं
- अपने developer से पूछें कि आपकी सबसे व्यस्त लिस्ट स्क्रीन हर row के लिए क्या लोड करती है, और क्या वह कुछ ऐसा लोड करती है जो स्क्रीन कभी दिखाती ही नहीं।
- पूछें कि जब कोई background task फेल होता है तो किसी को बताया जाता है या नहीं, और आज आपको कैसे पता चलेगा अगर कोई चुपचाप फेल हो रहा हो।
- अगर कोई error हटाने के लिए memory की सीमा बढ़ाने की सलाह दे, तो पहले पूछें कि स्क्रीन को असल में क्या चाहिए; ऊँची सीमा सिर्फ अगले, और बड़े रिकॉर्ड का इंतज़ार करती है।
- जब आप अपने system में किसी नई तरह का काम शुरू करें, जैसे कहीं लंबे documents या files, तो पूछें कि क्या कोई स्क्रीन एक आइटम के आकार से अटक सकती है।
- जिस स्क्रीन की किसी ने शिकायत की, वहीं रुक न जाएँ। पूछें कि क्या वही गड़बड़ी ऐसे tasks में भी है जिन्हें कोई देखता नहीं।
आगे क्या करें
वह लिस्ट लें जो आपकी टीम सबसे ज़्यादा इस्तेमाल करती है और वही सवाल पूछें जिसने यह मामला खोला: इस स्क्रीन को हर row के लिए क्या चाहिए, और यह फिर भी क्या लोड कर रही है। फिर ऐसा तरीका माँगें जिससे पता चले कि कोई background job फेल हुआ है, टूटी स्क्रीन से जानने के बजाय। इस तरह की गड़बड़ी की जड़ तक पहुँचना हमारे engineers का काम है, जो वे क्लाइंट के लिए करते हैं, और यह अक्सर एक सीधे सवाल से शुरू होता है कि कोई पेज असल में क्या माँग रहा है।
लोग जो पूछते हैं
मुझे कैसे पता चले कि कोई background task चुपचाप फेल हो रहा है?
अपने system की देखभाल करने वाले से पूछें कि scheduled jobs में फेल होना कहीं दर्ज होता है या नहीं और किसी को alert मिलता है या नहीं। अगर जवाब यह हो कि किसी को पता ही नहीं चलेगा, तो पहले यही ठीक करना चाहिए, क्योंकि फेल होता job तब तक कोई दिखने वाला लक्षण नहीं देता जब तक कोई उसके नतीजे पर निर्भर न हो।
जब किसी ने कुछ बदला ही नहीं, तो हमारी लिस्ट स्क्रीन क्यों टूट गई?
क्योंकि डेटा बदला, स्क्रीन नहीं। जो लिस्ट अपनी rows को क्रम में लगाती है, वह database से हर row को काम की memory में रखवाती है, और एक ऐसा रिकॉर्ड जो तय जगह से बड़ा हो जाए, पेज रोकने के लिए काफी है। ऐसा होने से पहले स्क्रीन खुद लंबे समय तक बिना बदले रह सकती है।
एक रिकॉर्ड पूरे पेज को लोड होने से कैसे रोक सकता है?
Database सारी rows को एक साथ क्रम में लगाता है, और क्रम में लगाते समय वह रिकॉर्ड के बड़े हिस्सों को छोड़ता नहीं। अगर एक row उस क्रम के लिए अलग रखी memory से बड़ी हो, तो पूरा काम फेल हो जाता है, और पेज के पास दिखाने को कुछ नहीं बचता। बाकी रिकॉर्ड छोटे होने से कोई फायदा नहीं होता।
क्या हमें बस database की memory सीमा बढ़ा देनी चाहिए?
सीमा बढ़ाने से error अभी के लिए गायब हो सकता है, लेकिन इसका जवाब नहीं देता कि पेज इतना क्यों लोड कर रहा था। अगला लंबा रिकॉर्ड नई सीमा पार कर सकता है, और वही फेल होना लौट आता है। बेहतर है कि पूछें कि स्क्रीन को असल में क्या चाहिए और सिर्फ वही लोड करें।
लिस्ट स्क्रीन को हर row के लिए क्या लोड करना चाहिए?
लिस्ट को सिर्फ वही fields लोड करनी चाहिए जो वह दिखाती है, जैसे title, state और date। लंबा टेक्स्ट, files या production की जानकारी उस पेज की होती है जो एक आइटम खोलता है। इससे लिस्ट तेज़ रहती है और एक बड़ा रिकॉर्ड उसे तोड़ नहीं पाता।