ब्राउझरमध्ये 5.5 MB चा Python runtime पाठवणारी एक टीम जेव्हा नुकत्याच झालेल्या स्प्रिंट दरम्यान नोंदवलेल्या त्रुटींचे (errors) विश्लेषण करत होती, तेव्हा त्यांना समजले की 69% त्रुटी एकाच चुकीच्या शीर्षकाखाली (misleading title) येत होत्या आणि त्यापैकी 89% त्रुटी प्रत्यक्षात नेटवर्क टाइमआउट्स (network timeouts) होत्या. या चुकीच्या रिपोर्टिंगमुळे डेव्हलपर्स चुकीच्या डीबगिंग मार्गावर वळले आणि मोठ्या प्रमाणात वापरकर्त्यांना डाऊनलोडमध्ये कोणतीही सूचना न देता त्रुटींचा सामना करावा लागला—ही अशी समस्या आहे जी मोठ्या प्रमाणात ॲसेट्स (assets) वापरणाऱ्या कोणत्याही वेब-ॲपमध्ये लवकरच उद्भवू शकते.

डॅशबोर्डने दिशाभूल केली

एरर-ट्रॅकिंग सिस्टम आपोआप अशा ठिकाणी घटनांचे गट करते जिथे त्या पहिल्यांदा दिसतात. परिणामी मिळालेले शीर्षक runtime loader मधील एक साधा बग असल्यासारखे वाटत होते, त्यामुळे संपूर्ण स्प्रिंट अशा कोड पाथ्सचा शोध घेण्यात वाया गेली ज्यामध्ये कधीही टाइमआउट झाले नव्हते. जेव्हा टीमने मूळ मेटाडेटाचे (metadata) नमुने तपासले, तेव्हा खरी परिस्थिती समोर आली: बहुतेक त्रुटी या बग्स नव्हत्या, तर नेटवर्क कनेक्शन थांबल्यामुळे (stalled) उद्भवलेले टाइमआउट्स होते.

Takeaway: एररचे शीर्षक हे केवळ सोयीसाठी असते, ते निदान (diagnosis) नसते. हेडलाईन प्रत्यक्षात काय दर्शवते हे तपासण्यासाठी वेळोवेळी मूळ डेटाचे (raw data) सखोल विश्लेषण करा.

ब्राउझर कनेक्शन API ने प्लेसहोल्डर दिले

स्लो इंटरनेट असलेल्या वापरकर्त्यांना 5.5 MB डाऊनलोडसाठी अडकवून न ठेवण्यासाठी, डेव्हलपर्सनी ब्राउझरच्या Network Information API (navigator.connection) चा वापर केला. या API ने प्रत्येक पहिल्यांदा येणाऱ्या वापरकर्त्यासाठी 1.7 Mbps बँडविड्थ (bandwidth) असल्याचे सांगितले.

जेव्हा ब्राउझरकडे नवीन वापरकर्त्यासाठी कोणताही ऐतिहासिक डेटा नसतो, तेव्हा तो एक डिफॉल्ट व्हॅल्यू (default value) देतो. ती डिफॉल्ट व्हॅल्यू केवळ एक संकेत (hint) असते, निश्चित वेग (speed) नाही. जेव्हा प्रत्येक नवीन सेशनसाठी तोच प्लेसहोल्डर दिसतो, तेव्हा त्याचा अर्थ असा होतो की API अजून त्या प्रेक्षकांसाठी (audience) योग्यरित्या कॅलिब्रेट झालेला नाही.

Takeaway: जो नेटवर्क सिग्नल कधीही बदलत नाही, त्याला एक 'फॉलबॅक' (fallback) माना, निश्चित मेट्रिक (metric) नाही.

वन-ऑफ स्नॅपशॉट्स (One-off snapshots) अविश्वसनीय आहेत

अविश्वसनीय बँडविड्थ हिंटचा त्याग केल्यानंतर, टीमने दुसऱ्या एका सिग्नलचा वापर करण्याचा निर्णय घेतला जो त्यांच्या टेस्ट सुईटमध्ये (test suite) काम करत असल्याचे वाटले. एक टेस्ट रन यशस्वी झाली, पण तीच टेस्ट तीन वेळा केल्यावर प्रत्येक वेळी त्रुटी आल्या. नेटवर्कचा वेग सतत बदलत असतो. कोडने केवळ एक स्नॅपशॉट घेतला, एक कायमस्वरूपी निर्णय घेतला आणि त्यानंतर कनेक्शन बदलले तरीही प्रक्रिया सुरू ठेवली.

Takeaway: बदलत्या गोष्टीच्या केवळ एका रीडिंगवर आधारित कायमस्वरूपी कृती करू नका. एकदाच पोलिंग (polling) करण्याऐवजी 'चेंज इव्हेंट्स'ला (change events) सबस्क्राईब करा.

टीमने अंमलात आणलेले व्यावहारिक उपाय

  • कनेक्शनमधील बदलांना सबस्क्राईब करा. navigator.connection एकदा वाचण्याऐवजी, कोड आता change इव्हेंटवर लक्ष ठेवतो आणि डाऊनलोड दरम्यान बँडविड्थ कमी किंवा जास्त झाल्यास त्यानुसार प्रतिक्रिया देतो.
  • “नो-प्रोग्रेस” वॉचडॉग (watchdog) जोडा. एक टाइमर ठराविक काळानंतर प्रगती न होणाऱ्या कोणत्याही विनंतीला (request) रद्द करतो, ज्यामुळे ब्राउझरला पुन्हा प्रयत्न करण्यासाठी किंवा फॉलबॅक करण्यासाठी वेळ मिळतो.
  • डाऊनलोड दरम्यान CDN बदलणे थांबवा. स्लो लिंकवर मोठ्या फाईलचा सोर्स बदलल्यामुळे ट्रान्सफर पुन्हा शून्यापासून सुरू होते, ज्यामुळे आधी मिळालेले बाइट्स वाया जातात. आता डाऊनलोड त्याच्या संपूर्ण कालावधीसाठी सुरुवातीला निवडलेल्या CDN लाच चिकटून राहतो.
  • जड कॅशिंग (caching) कामे पुढे ढकला. कॅशेमध्ये मोठ्या प्रमाणात डेटा लिहिणारी कामे रनटाइम लोड पूर्ण होईपर्यंत पुढे ढकलली जातात, ज्यामुळे क्रिटिकल पाथ (critical path) छोटा राहतो.

जर तुमचे डॅशबोर्ड्स अतिशय सुटसुटीत आणि अचूक चित्र दाखवत असतील, तर अधिक सखोल तपासणी करा. जर नेटवर्कचे मोजमाप कधीही बदलत नसेल, तर त्याला केवळ एक प्लेसहोल्डर माना. आणि जर एका स्नॅपशॉटमुळे अनेक मेगाबाइटच्या डाऊनलोडचे भवितव्य ठरत असेल, तर तुम्ही मृगजळावर (mirage) अवलंबून आहात. अशा निर्णयांचे परिणाम 'सायलेंट फेल्युअर' (silent failures) म्हणून समोर येतात जे वापरकर्त्याचा विश्वास कमी करतात—अशी गोष्ट जी नंतर कितीही हुशार कोड वापरून पूर्णपणे सुधारता येत नाही.