બ્રાઉઝર્સમાં 5.5 MB Python runtime મોકલતી એક ટીમે જોયું કે તાજેતરના સ્પ્રિન્ટ (sprint) દરમિયાન નોંધાયેલ 69% ભૂલો એક જ ગેરમાર્ગે દોરતા શીર્ષક હેઠળ હતી, અને તેમાંથી 89% વાસ્તવમાં network timeouts હતા. આ ખોટી રિપોર્ટિંગને કારણે ડેવલપર્સ ખોટા ડિબગિંગ (debugging) માર્ગ પર નીકળી ગયા અને મોટી સંખ્યામાં વપરાશકર્તાઓ silent download failures સાથે રહી ગયા—આ એક એવી સમસ્યા છે જે કોઈપણ મોટા assets ધરાવતું web-app ટૂંક સમયમાં અનુભવી શકે છે.

ડેશબોર્ડે ગેરમાર્ગે દોર્યું

error-tracking સિસ્ટમ ઘટનાઓને તે કોડ લોકેશન દ્વારા આપમેળે ગ્રુપ કરે છે જ્યાં તેઓ પ્રથમ દેખાય છે. પરિણામી શીર્ષક runtime loader માં એક સામાન્ય bug જેવું લાગતું હતું, તેથી સ્પ્રિન્ટનો સમય એવા code paths શોધવામાં વેડફાઈ ગયો જે ક્યારેય timeout થયા નહોતા. જ્યારે ટીમે અન્ડરલાઇંગ metadata નું સેમ્પલ લીધું, ત્યારે સાચું ચિત્ર સામે આવ્યું: મોટાભાગની નિષ્ફળતાઓ બગ્સ નહોતા પરંતુ અટકેલા network connections હતા જેના કારણે timeout થયું હતું.

Takeaway: ભૂલનું શીર્ષક એ માત્ર સુવિધા છે, નિદાન નથી. હેડલાઇન ખરેખર શું દર્શાવે છે તે ચકાસવા માટે સમયાંતરે raw data માં ઊંડાણપૂર્વક તપાસ કરો.

બ્રાઉઝર connection API એ પ્લેસહોલ્ડર આપ્યું

ધીમા વપરાશકર્તાઓને 5.5 MB ડાઉનલોડમાં લાંબો સમય ન ખર્ચવો પડે તે માટે, ડેવલપર્સે બ્રાઉઝરના Network Information API (navigator.connection) નો ઉપયોગ કર્યો. API એ દરેક પ્રથમ વખત આવતા મુલાકાતી માટે સતત 1.7 Mbps bandwidth દર્શાવ્યું.

જ્યારે બ્રાઉઝર પાસે નવા વપરાશકર્તા માટે કોઈ ઐતિહાસિક ડેટા હોતો નથી, ત્યારે તે default value આપે છે. તે default માત્ર એક સંકેત છે, ચોક્કસ સ્પીડ નથી. જ્યારે દરેક નવા સત્ર (session) માટે સમાન placeholder દેખાય છે, ત્યારે તે સંકેત આપે છે કે API હજુ તે પ્રેક્ષકો માટે કેલિબ્રેટ થયેલ નથી.

Takeaway: જે નેટવર્ક સિગ્નલ ક્યારેય બદલાતું નથી તેને fallback તરીકે ગણો, ચોક્કસ metric તરીકે નહીં.

વન-ઓફ (One-off) snapshots અવિશ્વસનીય છે

અવિશ્વસનીય bandwidth સંકેતનો ત્યાગ કર્યા પછી, ટીમે બીજા એક સંકેતનો ઉપયોગ કર્યો જે તેમના test suite માં કામ કરતો લાગતો હતો. એક ટેસ્ટ રન સફળ રહ્યો, પરંતુ ટેસ્ટને ત્રણ વાર દોર્યા પછી દરેક વખતે નિષ્ફળતા મળી. નેટવર્ક સ્પીડ સતત બદલાતી રહે છે. કોડે માત્ર એક જ snapshot લીધો, કાયમી નિર્ણય લીધો, અને જો ક્ષણભરમાં કનેક્શન બદલાઈ જાય તો પણ આગળ વધી ગયું.

Takeaway: બદલાતા લક્ષ્યના માત્ર એક જ રીડિંગ પર કાયમી નિર્ણય ન લો. માત્ર એકવાર polling કરવાને બદલે change events ને subscribe કરો.

ટીમે અમલમાં મૂકેલા વ્યવહારુ સુધારા

  • connection ફેરફારોને subscribe કરો. navigator.connection ને માત્ર એકવાર વાંચવાને બદલે, કોડ હવે change event સાંભળે છે અને જો ડાઉનલોડ દરમિયાન bandwidth ઘટે અથવા વધે તો પ્રતિક્રિયા આપે છે.
  • “no-progress” watchdog ઉમેરો. ટાઈમર એવા કોઈપણ રિક્વેસ્ટને અટકાવી દે છે જે ટૂંકા અંતરાલ પછી કોઈ પ્રગતિ કરતી નથી, જેથી બ્રાઉઝર ફરીથી પ્રયાસ કરી શકે અથવા fallback કરી શકે.
  • ડાઉનલોડની વચ્ચે CDN બદલવાનું બંધ કરો. ધીમા લિંક પર મોટી ફાઇલનો સ્ત્રોત બદલવાથી ટ્રાન્સફર ફરીથી શૂન્યથી શરૂ થાય છે, જેનાથી પહેલેથી પ્રાપ્ત થયેલા bytes વેડફાય છે. ડાઉનલોડ હવે તેની સમગ્ર અવધિ માટે શરૂઆતમાં પસંદ કરેલા CDN પર જ રહે છે.
  • ભારે caching કામને મોકૂફ રાખો. કેશ (cache) માં મોટી માત્રામાં ડેટા લખતા કાર્યો runtime લોડિંગ પૂર્ણ થયા પછી સુધી મોકૂફ રાખવામાં આવે છે, જેથી critical path ટૂંકો રહે છે.

જો તમારા ડેશબોર્ડ્સ ખૂબ જ વ્યવસ્થિત ચિત્ર રજૂ કરતા હોય, તો ઊંડાણપૂર્વક તપાસ કરો. જો નેટવર્કનું માપ ક્યારેય બદલાતું ન હોય, તો તેને placeholder તરીકે ગણો. અને જો એક જ snapshot મલ્ટી-મેગાબાઇટ ડાઉનલોડનું ભાગ્ય નક્કી કરતું હોય, તો તમે મૃગજળ પર દાવ લગાવી રહ્યા છો. આ દાવ 'silent failures' તરીકે દેખાય છે જે વપરાશકર્તાનો વિશ્વાસ તોડી નાખે છે—જેને પછીથી ગમે તેટલા ચતુર કોડ દ્વારા સંપૂર્ણ રીતે સુધારી શકાતું નથી.