ബ്രൗസറുകളിലേക്ക് 5.5 MB Python runtime എത്തിക്കുന്ന ഒരു ടീം, അവരുടെ ഒരു സമീപകാല സ്പ്രിന്റ് (sprint) സമയത്ത് രേഖപ്പെടുത്തിയ പിശകുകളിൽ (errors) 69% ഒരൊറ്റ തെറ്റായ തലക്കെട്ടിന് കീഴിലാണെന്നും, അവയിൽ 89% യഥാർത്ഥത്തിൽ നെറ്റ്‌വർക്ക് ടൈമൗട്ടുകൾ (network timeouts) ആണെന്നും കണ്ടെത്തി. ഈ തെറ്റായ റിപ്പോർട്ടിംഗ് ഡെവലപ്പർമാരെ തെറ്റായ ഡിബഗ്ഗിംഗ് പാതകളിലേക്ക് നയിക്കുകയും, വലിയൊരു വിഭാഗം ഉപയോക്താക്കൾക്ക് ഡൗൺലോഡ് പരാജയങ്ങൾ അനുഭവപ്പെടാൻ കാരണമാവുകയും ചെയ്തു—വലിയ അസറ്റുകൾ (assets) ഉൾക്കൊള്ളുന്ന ഏതൊരു വെബ് ആപ്പിനും ഉടൻ സംഭവിക്കാവുന്ന ഒരു പ്രശ്നമാണിത്.

ഡാഷ്‌ബോർഡ് തെറ്റിദ്ധരിപ്പിച്ചു

എറർ-ട്രാക്കിംഗ് സിസ്റ്റം, പിശകുകൾ ആദ്യമായി പ്രത്യക്ഷപ്പെടുന്ന കോഡ് ലൊക്കേഷൻ അനുസരിച്ച് അവയെ സ്വയമേവ ഗ്രൂപ്പ് ചെയ്യുന്നു. ഇതിന്റെ ഫലമായി ലഭിച്ച തലക്കെട്ട് റൺടൈം ലോഡറിലെ (runtime loader) ഒരു ചെറിയ ബഗ് ആണെന്ന് തോന്നിപ്പിച്ചു, അതിനാൽ ഒരിക്കലും ടൈമൗട്ട് ആകാത്ത കോഡ് പാത്തുകൾ (code paths) തിരയുന്നതിനായി സ്പ്രിന്റ് സമയം മുഴുവൻ ചിലവഴിച്ചു. ടീം അടിസ്ഥാന മെറ്റാഡാറ്റ (metadata) പരിശോധിച്ചപ്പോൾ യഥാർത്ഥ ചിത്രം വ്യക്തമായി: മിക്ക പരാജയങ്ങളും ബഗുകൾ ആയിരുന്നില്ല, മറിച്ച് ടൈമൗട്ടിന് കാരണമായ തടസ്സപ്പെട്ട നെറ്റ്‌വർക്ക് കണക്ഷനുകൾ ആയിരുന്നു.

ഗുണപാഠം: ഒരു എറർ ടൈറ്റിൽ എന്നത് സൗകര്യത്തിന് വേണ്ടിയുള്ളതാണ്, അത് ഒരു രോഗനിർണ്ണയമല്ല (diagnosis). തലക്കെട്ട് യഥാർത്ഥത്തിൽ എന്തിനെയാണ് സൂചിപ്പിക്കുന്നത് എന്ന് പരിശോധിക്കാൻ ഇടയ്ക്കിടെ റോ ഡാറ്റയിൽ (raw data) ആഴത്തിൽ പരിശോധിക്കുക.

ബ്രൗസർ കണക്ഷൻ API ഒരു പ്ലേസ്‌ഹോൾഡർ നൽകി

വേഗത കുറഞ്ഞ ഇന്റർനെറ്റ് ഉപയോഗിക്കുന്ന ഉപയോക്താക്കളെ 5.5 MB ഡൗൺലോഡ് വലിച്ചുനീക്കാൻ പ്രയാസപ്പെടുത്താതിരിക്കാൻ, ഡെവലപ്പർമാർ ബ്രൗസറിലെ Network Information API (navigator.connection) പരിശോധിച്ചു. ഓരോ പുതിയ സന്ദർശകനും 1.7 Mbps സ്ഥിരമായ ബാൻഡ്‌വിഡ്ത്ത് (bandwidth) ആണെന്ന് API റിപ്പോർട്ട് ചെയ്തു.

ഒരു പുതിയ ഉപയോക്താവിനെക്കുറിച്ച് മുൻകാല വിവരങ്ങൾ (historical data) ബ്രൗസറിന് ലഭ്യമല്ലെങ്കിൽ അത് ഒരു ഡിഫോൾട്ട് വാല്യൂ (default value) നൽകുന്നു. ആ ഡിഫോൾട്ട് വാല്യൂ ഒരു സൂചന മാത്രമാണ്, കൃത്യമായ വേഗതയല്ല. ഓരോ പുതിയ സെഷനിലും ഇതേ പ്ലേസ്‌ഹോൾഡർ കാണപ്പെടുന്നുണ്ടെങ്കിൽ, ആ വിഭാഗം ഉപയോക്താക്കൾക്കായി API ഇതുവരെ കാലിബ്രേറ്റ് ചെയ്തിട്ടില്ല എന്നാണ് അത് സൂചിപ്പിക്കുന്നത്.

ഗുണപാഠം: മാറ്റമില്ലാതെ തുടരുന്ന ഏതൊരു നെറ്റ്‌വർക്ക് സിഗ്നലിനെയും ഒരു ഫാള்பാക്ക് (fallback) ആയി മാത്രം കാണുക, അത് കൃത്യമായ ഒരു അളവുകോലായി (metric) കണക്കാക്കരുത്.

ഒറ്റത്തവണ സ്നാപ്‌ഷോട്ടുകൾ വിശ്വസനീയമല്ല

വിശ്വസനീയമല്ലാത്ത ബാൻഡ്‌വിഡ്ത്ത് സൂചന ഒഴിവാക്കിയ ശേഷം, ടീം അവരുടെ ടെസ്റ്റ് സ്യൂട്ടിൽ (test suite) പ്രവർത്തിക്കുന്നതായി തോന്നിയ മറ്റൊരു സിഗ്നലിലേക്ക് മാറി. ഒരു ടെസ്റ്റ് വിജയകരമായി നടന്നു, എന്നാൽ മൂന്ന് തവണ ആവർത്തിച്ചപ്പോൾ ഓരോ തവണയും പരാജയപ്പെട്ടു. നെറ്റ്‌വർക്ക് വേഗത നിരന്തരം മാറിക്കൊണ്ടിരിക്കും. കോഡ് ഒരു ഒറ്റത്തവണ സ്നാപ്‌ഷോട്ട് എടുക്കുകയും ഒരു സ്ഥിരമായ തീരുമാനം എടുക്കുകയും ചെയ്തു, അതിനുശേഷം കണക്ഷനിൽ മാറ്റം വന്നാലും അത് തുടർന്നുപോയി.

ഗുണപാഠം: മാറിക്കൊണ്ടിരിക്കുന്ന ഒരു കാര്യത്തെക്കുറിച്ച് (moving target) ഒരു ഒറ്റത്തവണ വായനയെ (single reading) അടിസ്ഥാനമാക്കി സ്ഥിരമായ തീരുമാനങ്ങൾ എടുക്കരുത്. ഒരു തവണ മാത്രം പരിശോധിക്കുന്നതിന് (polling) പകരം മാറ്റങ്ങൾ സംഭവിക്കുന്ന ഇവന്റുകൾക്കായി (change events) സബ്‌സ്‌ക്രൈബ് ചെയ്യുക.

ടീം നടപ്പിലാക്കിയ പ്രായോഗിക പരിഹാരങ്ങൾ

  • കണക്ഷൻ മാറ്റങ്ങൾക്കായി സബ്‌സ്‌ക്രൈബ് ചെയ്യുക. navigator.connection ഒരു തവണ മാത്രം വായിക്കുന്നതിന് പകരം, ഡൗൺലോഡ് സമയത്ത് ബാൻഡ്‌വിഡ്ത്ത് കുറയുകയോ കൂടുകയോ ചെയ്താൽ പ്രതികരിക്കുന്നതിനായി കോഡ് ഇപ്പോൾ change ഇവന്റിനായി കാതോർക്കുന്നു.
  • ഒരു “no-progress” വാച്ച്ഡോഗ് (watchdog) ചേർക്കുക. ഒരു നിശ്ചിത സമയത്തിന് ശേഷവും പുരോഗതിയില്ലാത്ത ഏതൊരു റിക്വസ്റ്റും ഒരു ടൈമർ റദ്ദാക്കുന്നു, ഇത് ബ്രൗസറിന് വീണ്ടും ശ്രമിക്കാനോ പകരമുള്ള മാർഗ്ഗങ്ങൾ സ്വീകരിക്കാനോ അവസരം നൽകുന്നു.
  • ഡൗൺലോഡിടെ CDN മാറ്റുന്നത് നിർത്തുക. വേഗത കുറഞ്ഞ കണക്ഷനിൽ ഒരു വലിയ ഫയലിന്റെ സ്രോതസ്സ് (source) മാറ്റുന്നത് ഡൗൺലോഡ് പൂജ്യത്തിൽ നിന്ന് വീണ്ടും തുടങ്ങാൻ കാരണമാവുകയും ഇതിനോടകം ലഭിച്ച ഡാറ്റ പാഴാക്കുകയും ചെയ്യുന്നു. ഡൗൺലോഡ് ഇപ്പോൾ തുടക്കത്തിൽ തിരഞ്ഞെടുത്ത CDN തന്നെ മുഴുവൻ സമയവും ഉപയോഗിക്കുന്നു.
  • ഭാരമേറിയ കാഷിംഗ് (caching) ജോലികൾ മാറ്റിവെക്കുക. വലിയ അളവിൽ ഡാറ്റ കാഷിലേക്ക് എഴുതുന്ന ജോലികൾ റൺടൈം ലോഡിംഗ് പൂർത്തിയാകുന്നത് വരെ മാറ്റിവെക്കുന്നു, ഇത് പ്രധാന പ്രക്രിയയുടെ വേഗത നിലനിർത്തുന്നു.

നിങ്ങളുടെ ഡാഷ്‌ബോർഡുകൾ അവിശ്വസനീയമാംവിധം കൃത്യമായ ചിത്രം നൽകുന്നുണ്ടെങ്കിൽ, കൂടുതൽ ആഴത്തിൽ പരിശോധിക്കുക. ഒരു നെറ്റ്‌വർക്ക് അളവ് ഒരിക്കലും മാറുന്നില്ലെങ്കിൽ, അതിനെ ഒരു പ്ലേസ്‌ഹോൾഡറായി കണക്കാക്കുക. ഒരു ഒറ്റത്തവണ സ്നാപ്‌ഷോട്ട് ഒരു വലിയ ഡൗൺലോഡിന്റെ വിധി തീരുമാനിക്കുന്നുണ്ടെങ്കിൽ, നിങ്ങൾ ഒരു മിഥ്യയെയാണ് വിശ്വസിക്കുന്നത്. ഇത്തരം തെറ്റായ തീരുമാനങ്ങൾ ഉപയോക്താക്കളുടെ വിശ്വാസം നഷ്ടപ്പെടുത്തുന്ന നിശബ്ദ പരാജയങ്ങളായി (silent failures) മാറുന്നു—ഇത് പിന്നീട് എത്ര മികച്ച കോഡ് ഉപയോഗിച്ചാലും പൂർണ്ണമായി പരിഹരിക്കാൻ കഴിയില്ല.