Playwright അല്ലെങ്കിൽ Puppeteer വഴി ഒരു Chrome DevTools debugger ഘടിപ്പിക്കുന്നത് fetch-അധിഷ്ഠിത അപ്‌ലോഡുകളെ 20 മടിക്കും अधिक മന്ദഗതിയിലാക്കുന്നുവെന്നും, ഇത് ദൈനംദിന പെർഫോമൻസ് ബെഞ്ച്മാർക്കുകളെ തെറ്റായ വിവരങ്ങളാക്കി മാറ്റുന്നുവെന്നും ഒരു ഡെവലപ്പർ കണ്ടെത്തി.

അന്വേഷണത്തിന് തുടക്കമിട്ട പസിൽ

സെർവറിലേക്ക് അയക്കുന്നതിന് മുമ്പ് ഡാറ്റ എൻക്രിപ്റ്റ് ചെയ്യുന്ന ബ്രൗസർ അധിഷ്ഠിത ഫയൽ സ്റ്റോറായ Coffer, ലോക്കൽ നെറ്റ്‌വർക്കിലൂടെ ഗിഗാബിറ്റ് ക്ലാസ് അപ്‌ലോഡുകൾ പതിവായി ചെയ്യുന്നുണ്ട്. ടീം അപ്‌ലോഡ് വേഗത അളന്നപ്പോൾ ഒരു വ്യത്യാസം കണ്ടു: ഡൗൺലോഡുകൾ ലിങ്കിന്റെ മുഴുവൻ ശേഷിയും ഉപയോഗിക്കുന്നുണ്ടെങ്കിലും, അപ്‌ലോഡുകൾ ലഭ്യമായ ബാൻഡ്‌വിഡ്ത്തിന്റെ ഏകദേശം എട്ടിലൊന്ന് വേഗതയിൽ മാത്രമാണ് നടന്നത്. ഈ വ്യത്യാസം പരിഹരിക്കാൻ മൂന്ന് തവണ കോഡ് മാറ്റങ്ങൾ വരുത്തിയെങ്കിലും മാറ്റമൊന്നും ഉണ്ടായില്ല. എന്നാൽ നാലാമത്തെ ഒരു “fix” വലിയൊരു കുതിച്ചുചാട്ടം നൽകുന്നതായി തോന്നി—പക്ഷേ ഡീബഗ്ഗർ നീക്കം ചെയ്തപ്പോൾ അത് അപ്രത്യക്ഷമായി.

ടീം ആദ്യം പരീക്ഷിച്ചവ

എഞ്ചിനീയർമാർ സാധാരണയായി സംശയിക്കുന്ന കാര്യങ്ങളാണ് ആദ്യം പരിശോധിച്ചത്:

  • Chunk size – ബ്ലോക്ക് സൈസ് 16 MiB-ൽ നിന്ന് 32 MiB ആയി ഇരട്ടിയാക്കിയെങ്കിലും Throughput-ൽ മാറ്റമുണ്ടായില്ല.
  • Pipelining – നിലവിലെ അപ്‌ലോഡിനൊപ്പം അടുത്ത ബ്ലോക്കിന്റെ എൻക്രിപ്ഷൻ കൂടി ഒരേസമയം പ്രവർത്തിപ്പിച്ചത് 13% മാത്രം നേട്ടമുണ്ടാക്കി, ഇത് അളവുകളിലെ സാധാരണ വ്യത്യാസമായി കണക്കാക്കാം.
  • Concurrency – ഒന്നിലധികം അപ്‌ലോഡുകൾ സമാന്തരമായി (parallel) പ്രവർത്തിപ്പിച്ചത് ആകെ വേഗതയിൽ മാറ്റം വരുത്തിയില്ല, ഇത് ഒരു ആഗോള പരിധി (global ceiling) ഉണ്ടെന്ന് സൂചിപ്പിക്കുന്നു.

ഈ മാറ്റങ്ങളൊന്നും 8 മടങ്ങ് വേഗത കുറയുന്നതിന് കാരണം വ്യക്തമാക്കിയില്ല.

അപ്രതീക്ഷിതമായ ഒരു താരതമ്യം

പ്രശ്നം കണ്ടെത്താനായി ടീം ക്ലയന്റ് ഇംപ്ലിമെന്റേഷൻ മാറ്റി പരീക്ഷിച്ചു. .NET HttpClient ഉപയോഗിച്ചപ്പോൾ അതേ നെറ്റ്‌വർക്കിൽ അവർക്ക് 700 Mbps വേഗത ലഭിച്ചു; എന്നാൽ ഇതേ റിക്വസ്റ്റ് Chromium-ന്റെ fetch() API ഉപയോഗിച്ച് അയച്ചപ്പോൾ അത് 140 Mbps-ൽ തടസ്സപ്പെട്ടു. ഈ വലിയ വ്യത്യാസം ബ്രൗസറുടെ നെറ്റ്‌വർക്ക് സ്റ്റാക്കിനെയാണ് കുറ്റക്കാരനായി ചൂണ്ടിക്കാണിച്ചത്—എന്നാൽ അടുത്ത പരീക്ഷണം മറ്റൊന്ന് തെളിയിച്ചു.

ഡീബഗ്ഗറിന്റെ മറഞ്ഞിരിക്കുന്ന വില

Playwright-ഉം Puppeteer-ഉം Chrome DevTools Protocol (CDP) വഴിയാണ് Chrome-നെ നിയന്ത്രിക്കുന്നത്. ഈ പ്രോട്ടോക്കോൾ ബ്രൗസർ പ്രോസസ്സിൽ ഒരു ഡീബഗ്ഗർ ഘടിപ്പിക്കുകയും നെറ്റ്‌വർക്ക് ഇവന്റുകൾ, DOM സ്നാപ്പ്ഷോട്ടുകൾ, കൺസോൾ ലോഗുകൾ എന്നിവ ലഭ്യമാക്കുകയും ചെയ്യുന്നു. ടീം ഒരു പ്രത്യേക പരീക്ഷണം നടത്തി: ഒരു Uint8Array പേലോഡ് അയക്കുന്ന fetch() കോൾ, ഒരിക്കൽ CDP ഡീബഗ്ഗർ ഘടിപ്പിച്ചും മറ്റൊരിക്കൽ ഘടിപ്പിക്കാതെയും പരീക്ഷിച്ചു.

  • Debugger attached: 113 Mbps

ഡീബഗ്ഗറിന്റെ സാന്നിധ്യം അപ്‌ലോഡ് വേഗത 20 മടിക്കും अधिक കുറച്ചു. ഡീബഗ്ഗർ ഇല്ലാത്ത ഒരു സാധാരണ Edge വിൻഡോയിൽ നടത്തിയ മാനുവൽ ടെസ്റ്റിൽ 600 + Mbps വേഗത ലഭിച്ചു, ഇത് തടസ്സങ്ങളില്ലാത്തപ്പോൾ ബ്രൗസറിന് ഉയർന്ന ട്രാഫിക് കൈകാര്യം ചെയ്യാൻ കഴിയുമെന്ന് സ്ഥിരീകരിച്ചു.

ചെറിയൊരു യഥാർത്ഥ പുരോഗതി

വേഗത കുറയുന്നതിന്റെ പ്രധാന കാരണം ഡീബഗ്ഗർ ആണെങ്കിലും, ടീം ഒരു യഥാർത്ഥ ഒപ്റ്റിമൈസേഷൻ കണ്ടെത്തി: റിക്വസ്റ്റ് ബോഡി Uint8Array-ൽ നിന്ന് Blob-ലേക്ക് മാറ്റിയത് Chromium-ന്റെ വേഗത ഏകദേശം 30 % വർദ്ധിപ്പിച്ചു. ഇത് ഉപകാരപ്രദമായ ഒരു മാറ്റമാണെങ്കിലും, ആദ്യം പ്രതീക്ഷിച്ച ആ “അത്ഭുതകരമായ” വർദ്ധനവിനോട് ഇതിനെ താരതമ്യം ചെയ്യാൻ കഴിയില്ല.

ഇത് എഞ്ചിനീയർമാർക്ക് എന്തുകൊണ്ട് പ്രധാനമാണ്

  • ഉപകരണങ്ങൾ തെറ്റായ വിവരങ്ങൾ നൽകിയേക്കാം. ബ്രൗസറുകളെ ഓട്ടോമേറ്റ് ചെയ്യുന്ന പെർഫോമൻസ് ടൂളുകൾ തന്നെ അളവുകളുടെ ഭാഗമാണ്.
  • അസാധ്യമായി തോന്നുന്ന ബെഞ്ച്മാർക്കുകൾ പരിശോധിക്കേണ്ടതുണ്ട്. കണക്കുകൾ നെറ്റ്‌വർക്ക് ശേഷിയേക്കാൾ വളരെ കുറവാണെങ്കിൽ, അളക്കുന്ന രീതിയാണ് (measurement environment) ആദ്യം സംശയിക്കേണ്ടത്.
  • ഫലമില്ലാത്ത കണ്ടെത്തലുകളും വിലപ്പെട്ടതാണ്. ഒരു മാറ്റം കൊണ്ട് മാറ്റമൊന്നും സംഭവിക്കുന്നില്ലെന്ന് ഉറപ്പാക്കുന്നത് അനാവശ്യമായ പരിശ്രമങ്ങൾ ഒഴിവാക്കാൻ സഹായിക്കുന്നു.
  • മാനുവൽ പരിശോധനകൾ സുരക്ഷിതമാണ്. ഒരു സാധാരണ ബ്രൗസർ വിൻഡോയിൽ ഒരേ കാര്യം പരീക്ഷിക്കുന്നത് മറഞ്ഞിരിക്കുന്ന ഇൻസ്ട്രുമെന്റേഷൻ ഓവർഹെഡ് (instrumentation overhead) കണ്ടെത്താൻ സഹായിക്കും.

മറ്റൊരു വശം: ഡീബഗ്ഗറുകൾ അനിവാര്യമാകുന്ന സാഹചര്യങ്ങൾ

പേജ് പെരുമാറ്റം, എറർ ട്രാസുകൾ, നെറ്റ്‌വർക്ക് ടൈംലൈനുകൾ എന്നിവ മനസ്സിലാക്കാൻ ഡീബഗ്ഗറുകൾ സഹായിക്കുന്നു. റിഗ്രഷൻ ടെസ്റ്റിംഗിനും, സെക്യൂരിറ്റി ഓഡിറ്റിനും, സങ്കീർണ്ണമായ UI ഇന്ററാക്ഷനുകൾക്കും ഒരു CDP ഡീബഗ്ഗർ ഉപയോഗിക്കേണ്ടത് പലപ്പോഴും അനിവാര്യമാണ്. ഫങ്ഷണൽ ടെസ്റ്റിംഗിനെയും പെർഫോമൻസ് മെഷർമെന്റിനെയും വേർതിരിക്കുക എന്നതാണ് പ്രധാനം; പെർഫോമൻസ് അളക്കുകയാണ് ലക്ഷ്യമെങ്കിൽ ഡീബഗ്ഗർ ഓഫ് ചെയ്യണം.

ചുരുക്കത്തിൽ: ഓട്ടോമേറ്റഡ് ടെസ്റ്റിംഗ് സാധ്യമാക്കുന്ന ടൂളുകൾ തന്നെ പെർഫോമൻസ് തെറ്റായി കാണിക്കുന്നതിന്റെ പ്രധാന കാരണമായി മാറിയേക്കാം. ബ്രൗസിനെയോ നെറ്റ്‌വർക്കിനെയോ കോഡിനെയോ കുറ്റപ്പെടുത്തുന്നതിന് മുമ്പ്, ഒരു ഡീബഗ്ഗർ ഡാറ്റാ സ്ട്രീമിനെ തടസ്സപ്പെടുത്തുന്നുണ്ടോ എന്ന് പരിശോധിക്കുക.