બ્રાઉઝર-આધારિત Python પ્લેગ્રાઉન્ડ, જે 5.5 MB રનટાઇમ (runtime) સાથે આવે છે, તે ધીમા કનેક્શન ધરાવતા વપરાશકર્તાઓ માટે અચાનક નિષ્ફળ જવા લાગ્યું. આનું કારણ Network Information API નો ખોટો ઉપયોગ અને એરર-ગ્રુપિંગ (error-grouping) ડેશબોર્ડ હતું જેણે સમસ્યાને ખોટી રીતે દર્શાવી હતી. આ બગ (bug) અઠવાડિયા સુધી છુપાયેલો રહ્યો, ડેવલપરનો સમય બગાડ્યો અને વપરાશકર્તાઓના એક ભાગને કોડ ચલાવવામાં અસમર્થ બનાવ્યા.

સમસ્યા કેવી રીતે સામે આવી

પ્લેગ્રાઉન્ડના એરર ટ્રેકરે એક જ, ધ્યાન ખેંચે તેવો સંદેશ દર્શાવ્યો: “undefined is not an object.” આ શીર્ષક સૂચવતું હતું કે આ એક સામાન્ય JavaScript ટાઈપો (typo) છે, તેથી ટીમ એક અસ્તિત્વમાં ન હોય તેવા કોડ પાથ (code path) પાછળ દોડી. જ્યારે તેઓએ રો (raw) મેટાડેટાની તપાસ કરી, ત્યારે તેઓએ જોયું કે તેમાંથી 89% ઘટનાઓ વાસ્તવમાં નેટવર્ક ટાઈમઆઉટ (network timeouts) હતી. ડેશબોર્ડે જે પહેલો એરર આવ્યો તેને લીધો અને આખા બેચનું નામ આપવા માટે તેનો ઉપયોગ કર્યો, જેનાથી સાચી નિષ્ફળતાનો પ્રકાર છુપાઈ ગયો.

પાઠ ૧ – ડેશબોર્ડના શીર્ષકો ભ્રામક હોઈ શકે છે

જે ડેશબોર્ડ ઘટનાઓનું એકત્રીકરણ (aggregates) કરે છે તે ત્યારે જ મદદરૂપ થાય છે જો તેનું એગ્રીગેશન લોજિક દરેક ઘટનાના વાસ્તવિક કારણને પ્રતિબિંબિત કરતું હોય. અહીં, એરરના કારણને બદલે લોકેશન દ્વારા ગ્રુપિંગ કરવાથી ક્લાયન્ટ-સાઇડ બગનું ખોટું ચિત્ર રજૂ થયું. બોધપાઠ: માત્ર ડેશબોર્ડના હેડલાઇન પર આધાર રાખીને ક્યારેય સમસ્યાનો ઉકેલ ન લાવો. સંસાધનો (resources) ફાળવતા પહેલા, મૂળભૂત ઘટનાઓનો નમૂનો લો અને ખરેખર શું થઈ રહ્યું છે તેની ખાતરી કરો.

પાઠ ૨ – પ્લેસહોલ્ડર (Placeholder) કિંમતો એ માપન નથી

ધીમા કનેક્શન ધરાવતા વપરાશકર્તાઓ માટે ભારે રનટાઇમ લોડ કરવાનું ટાળવા માટે, કોડે Network Information API નો ઉપયોગ કર્યો અને downlink પ્રોપર્ટી વાંચી, જે મેગાબિટ્સ પ્રતિ સેકન્ડ રિપોર્ટ કરે છે. પ્રથમ મુલાકાત પર, Chrome ઘણીવાર વાસ્તવિક માપન ને બદલે પ્લેસહોલ્ડર આપે છે. લોજિકે તે પ્લેસહોલ્ડરને ઝડપી કનેક્શન તરીકે ગણ્યું અને ઓપ્ટિમાઇઝેશન સ્કીપ કરી દીધું, જેનાથી તે જ વપરાશકર્તાઓ અટકી ગયા જેમને મદદ કરવાનો હેતુ હતો.

કોઈપણ ડિફોલ્ટ અથવા સેન્ટિનલ (sentinel) વેલ્યુને "ડેટા નથી" તરીકે ગણો. પ્લેસહોલ્ડર એ ફોલબેક વ્યૂહરચના (fallback strategy) શરૂ કરવું જોઈએ, તેને વાસ્તવિક સ્પીડ રીડિંગ તરીકે સમજવું જોઈએ નહીં.

પાઠ ૩ – નેટવર્કની સ્થિતિ બદલાતી રહે છે, તેથી સિંગલ સ્નેપશોટ અવિશ્વસનીય છે

downlink ની સમસ્યા પછી, ટીમે effectiveType તપાસવાનું શરૂ કર્યું, જે કનેક્શનને “4g”, “3g” વગેરે તરીકે વર્ગીકૃત કરે છે. એક ઝડપી લેબ ટેસ્ટ સફળ રહ્યો, પરંતુ થોડી ક્ષણો પછી તે જ ટેસ્ટ ફરીથી ચલાવતા નિષ્ફળ ગયો. મોબાઈલ કનેક્શનમાં વધઘટ થાય છે; વપરાશકર્તા એક સેકન્ડમાં ઝડપી 4G લિંક પર હોઈ શકે છે અને બીજી સેકન્ડમાં ધીમા 3G પર આવી શકે છે. માત્ર પેજ લોડ વખતે જ કનેક્શન તપાસવું એ જોખમી છે.

સાચી પદ્ધતિ એ છે કે એકવારનો નિર્ણય લેવાને બદલે Network Information ઓબ્જેક્ટ પર change ઇવેન્ટ માટે સબ્સ્ક્રાઇબ (subscribe) કરવું અને બેન્ડવિડ્થમાં આવતા કોઈપણ ફેરફાર સામે પ્રતિક્રિયા આપવી.

ટીમે શું બદલ્યું

  • ટુ-સ્ટેજ ડાઉનલોડ (Two-stage download) – રનટાઇમ હવે એક નાની બુટસ્ટ્રેપ (bootstrap) ફાઇલ સાથે શરૂ થાય છે. જો કનેક્શન ધીમું હોવાનું જણાય, તો બુટસ્ટ્રેપ બાકીનું રનટાઇમ નાના ટુકડાઓમાં (chunks) મેળવે છે, જેનાથી ડાઉનલોડ સંપૂર્ણપણે અટકી જવાની શક્યતા ઘટે છે.
  • લાઇવ મોનિટરિંગ (Live monitoring) – માત્ર એકવાર downlink વાંચવાને બદલે, કોડ હવે change ઇવેન્ટ્સ સાંભળે છે અને ડાઉનલોડ વ્યૂહરચનાને તરત જ (on the fly) એડજસ્ટ કરે છે.
  • સ્થિર સોર્સ પસંદગી (Stable source selection) – અગાઉ જ્યારે કોઈ ઝડપી એન્ડપોઈન્ટ દેખાય ત્યારે સિસ્ટમ ડાઉનલોડની વચ્ચે જ CDNs બદલી નાખતી હતી. ધીમા કનેક્શન પર આના કારણે ડાઉનલોડ શૂન્યથી ફરી શરૂ થતું હતું, જેનાથી સમસ્યા વધુ વણસી જતી હતી. નવું લોજિક ડાઉનલોડ દરમિયાન સોર્સને લોક (lock) કરી દે છે.
  • ડિફર્ડ કેશ રાઈટ્સ (Deferred cache writes) – એપ ઉપયોગમાં લેવા યોગ્ય બને તે પહેલાં જે ભારે કેશ કામગીરી (cache operations) ચાલતી હતી, તેને હવે રનટાઇમ શરૂ થયા પછી સુધી મોકૂફ રાખવામાં આવી છે, જેથી મહત્વપૂર્ણ ડાઉનલોડ માટે બેન્ડવિડ્થ ખાલી રહે.

વ્યાપક જોખમો

વેબ-આધારિત ટૂલ્સ બનાવતા ડેવલપર્સ માટે, નેટવર્કની અસ્થિરતા એ એક મુખ્ય ચિંતા છે. ધીમા કનેક્શન પર થતી છૂપી નિષ્ફળતા વપરાશકર્તાઓને નિરાશ કરે છે અને ટેલિમેટ્રી (telemetry) ને ખોટી રીતે દર્શાવે છે, જેનાથી ટીમો ખોટા ડિબગિંગ માર્ગ પર જાય છે. આ કિસ્સામાં, ડેટાના ખોટા અર્થઘટનને કારણે અઠવાડિયા સુધી નિરર્થક તપાસ કરવી પડી હતી.

આગળ શું ધ્યાન રાખવું

બોધપાઠ: જ્યારે ડેટા ખૂબ જ ચોખ્ખો (clean) દેખાય, ત્યારે તે કદાચ પ્લેસહોલ્ડર હોઈ શકે છે; જ્યારે ડેશબોર્ડનું હેડલાઇન કોઈ એક જ બગ તરફ નિર્દેશ કરે, ત્યારે વધુ ઊંડાણપૂર્વક તપાસ કરો; અને જ્યારે તમે એક વખતની નેટવર્ક રીડ પર આધાર રાખીને નિર્ણય લો છો, ત્યારે તમે અનિશ્ચિત લક્ષ્ય પર દાવ લગાવી રહ્યા છો. આ વાસ્તવિકતાઓ મુજબ અનુકૂલન સાધવાથી છૂપી નિષ્ફળતાઓ એ અનુમાનિત અને સુધારી શકાય તેવી ઘટનાઓમાં બદલાઈ જાય છે.