Playwright அல்லது Puppeteer மூலம் Chrome DevTools debugger-ஐ இணைக்கும்போது, fetch-அடிப்படையிலான uploads 20 மடங்குக்கும் அதிகமாகத் தடையுண்டாக்குகிறது (throttle) என்பதைக் கண்டறிந்தார் ஒரு டெவலப்பர். இது அன்றாட செயல்திறன் அளவீடுகளை (performance benchmarks) தவறான தரவுகளாக மாற்றுகிறது.

ஆய்வைத் தூண்டிய புதிர்

Coffer என்பது சர்வர் அனுப்பும் முன் தரவை என்க்ரிப்ட் (encrypt) செய்யும் ஒரு பிரவுசர் சார்ந்த கோப்பு சேமிப்பு (file store) ஆகும். இது உள்ளூர் நெட்வொர்க்கில் வழக்கமாக gigabit-வகுப்பு uploads-களை அனுப்புகிறது. குழுவினர் upload வேகத்தை அளவிட்டபோது, ஒரு இடைவெளியைக் கண்டறிந்தனர்: downloads இணைப்பை முழுமையாகப் பயன்படுத்தின, ஆனால் uploads கிடைக்கும் பேண்ட்வித் அளவில் (bandwidth) சுமார் எட்டில் ஒரு பங்கு வேகத்தில் மட்டுமே நகர்ந்தன. இந்த முரண்பாடு மூன்று முறை குறியீடு மாற்றங்களைச் செய்யத் தூண்டியது, ஆனால் அவை எந்த மாற்றத்தையும் ஏற்படுத்தவில்லை. நான்காவது ஒரு "தீர்வு" மிகப்பெரிய முன்னேற்றத்தைத் தருவது போல் தோன்றியது—ஆனால் debugger நீக்கப்பட்டவுடன் அது மறைந்து போனது.

குழு முதலில் முயற்சித்தவை

பொதுவாகச் சந்திக்கப்படும் காரணிகளைப் பொறியாளர்கள் ஆராய்ந்தனர்:

  • Chunk size – பிளாக்கை (block) 16 MiB-லிருந்து 32 MiB-ஆக இரட்டிப்பாக்கியும், அதன் throughput மாறாமல் இருந்தது.
  • Pipelining – தற்போதைய upload உடன் அடுத்த பிளாக்கின் encryption-ஐச் சேர்த்துச் செய்தபோது, 13% மட்டுமே சிறிய முன்னேற்றம் கிடைத்தது; இது அளவீட்டுப் பிழையாகவும் (measurement noise) இருக்கலாம்.
  • Concurrency – பல uploads-களை இணையாக (parallel) இயக்கியும், மொத்த வேகம் அதே அளவில் இருந்தது, இது ஒரு உலகளாவிய வரம்பைக் (global ceiling) குறிக்கிறது.

இந்த மாற்றங்களில் எதுவுமே அந்த 8 மடங்கு வேகக் குறைவை விளக்கவில்லை.

ஒரு ஆச்சரியமான நேரடி ஒப்பீடு

சிக்கலைத் தனிமைப்படுத்த, குழுவினர் client implementation-ஐ மாற்றினர். .NET HttpClient-ஐப் பயன்படுத்தி அதே நெட்வொர்க்கில் 700 Mbps வேகத்தைப் பதிவு செய்தனர்; அதே கோரிக்கையை (request) Chromium-ன் fetch() API மூலம் அனுப்பியபோது அது 140 Mbps-இல் நின்றுவிட்டது. இந்தத் தெளிவான வேறுபாடு பிரவுசரின் network stack-ஐக் குற்றவாளியாகக் காட்டியது—அடுத்த சோதனை அதைத் தவறென்று நிரூபிக்கும் வரை.

Debugger-ன் மறைமுகச் செலவு

Playwright மற்றும் Puppeteer ஆகியவை Chrome DevTools Protocol (CDP) மூலம் Chrome-ஐ இயக்குகின்றன. அந்த Protocol பிரவுசர் செயல்பாட்டிற்கு ஒரு debugger-ஐ இணைத்து, network events, DOM snapshots மற்றும் console logs ஆகியவற்றை வெளிப்படுத்துகிறது. குழுவினர் ஒரு குறிப்பிட்ட சோதனையைச் செய்தனர்: ஒரு Uint8Array payload-ஐ அனுப்பும் fetch() அழைப்பு, ஒருமுறை CDP debugger இணைக்கப்பட்ட நிலையிலும், மற்றொரு முறை இணைக்கப்படாத நிலையிலும் செய்யப்பட்டது.

  • Debugger இணைக்கப்பட்ட நிலையில்: 113 Mbps

Debugger இருந்ததால் upload வேகம் 20 மடங்குக்கும் அதிகமாகக் குறைந்தது. ஒரு சாதாரண Edge விண்டோவில்—debugger இணைக்கப்படாமல்—கைமுறையாகச் செய்த சோதனை 600 + Mbps வேகத்தை எட்டியது, இது எந்தத் தடையும் இல்லாதபோது பிரவுசரால் அந்தப் போக்குவரத்தைக் கையாள முடியும் என்பதை உறுதிப்படுத்தியது.

ஒரு சிறிய, உண்மையான முன்னேற்றம்

வேகக் குறைவுக்கு debugger தான் முக்கியக் காரணம் என்றாலும், குழுவினர் ஒரு உண்மையான மேம்பாட்டைக் (optimization) கண்டறிந்தனர்: request body-யை Uint8Array-லிருந்து Blob-ஆக மாற்றியதன் மூலம் Chromium-ன் வேகம் சுமார் 30 % அதிகரித்தது. இது ஒரு பயனுள்ள மாற்றம் தான், ஆனால் முதலில் எதிர்பார்த்த அந்த "அற்புதமான" (miracle) உயர்வுக்கு இது ஈடாகாது.

இது பொறியாளர்களுக்கு ஏன் முக்கியமானது

  • கருவிகள் பொய் சொல்லலாம். பிரவுசர்களைத் தானியக்கமாக்கும் (automate) செயல்திறன் கருவிகளே அளவீட்டுச் சங்கிலியின் ஒரு பகுதியாகும்.
  • சாத்தியமற்றதாகத் தோன்றும் benchmarks-களைச் சரிபார்க்க வேண்டும். எண்கள் நெட்வொர்க் திறனில் இருந்து வெகுவாக விலகி இருந்தால், அளவீட்டுச் சூழலே (measurement environment) முதல் சந்தேகத்திற்குரியதாக இருக்க வேண்டும்.
  • ஒரு 'null' முடிவு மதிப்புமிக்கது. ஒரு மாற்றம் எதையும் செய்யவில்லை என்பதை உறுதிப்படுத்துவது, கற்பனையான பிழைகளைத் (phantom bugs) தேடி நேரத்தை வீணடிப்பதைத் தவிர்க்கிறது.
  • கைமுறைக் கட்டுப்பாடுகள் (Manual controls) சிறந்த பாதுகாப்பு. ஒரு சாதாரண பிரவுசர் விண்டோவில் அதே செயல்பாட்டைச் செய்து பார்ப்பது, மறைந்திருக்கும் instrumentation overhead-ஐ வெளிப்படுத்தலாம்.

மாற்றுக்கருத்து: debuggers எப்போது தவிர்க்க முடியாதவை

Debuggers பக்கத்தின் செயல்பாடு (page behavior), பிழைத் தடங்கள் (error traces) மற்றும் நெட்வொர்க் காலவரிசை (network timelines) ஆகியவற்றைப் பார்க்க உதவுகின்றன, இவை வேறு வழியில் அணுக முடியாதவை. Regression testing, பாதுகாப்புத் தணிக்கை (security audits) அல்லது சிக்கலான UI தொடர்புகளுக்கு, ஒரு CDP debugger-ஐ இணைப்பது பெரும்பாலும் தவிர்க்க முடியாதது. செயல்பாட்டுச் சோதனைக்கும் (functional testing) நேரடி செயல்திறன் அளவீட்டிற்கும் (raw performance measurement) இடையே வேறுபாடு காண்பதே முக்கியம்; செயல்திறன் அளவீடுதான் இலக்காக இருக்கும்போது debugger-ஐ முடக்கிவிட வேண்டும்.

சுருக்கம்: தானியங்கிச் சோதனையைச் சாத்தியமாக்கும் கருவிகளே செயல்திறன் சிதைவின் (performance distortion) மிகப்பெரிய ஆதாரமாகவும் மாறக்கூடும். பிரவுசர், நெட்வொர்க் அல்லது குறியீட்டைத்탓ப்பதற்கு முன், எந்த debugger-உம் தர ஓட்டத்தைத் (data stream) மௌனமாகத் தடுக்கவில்லை என்பதை உறுதிப்படுத்திக் கொள்ளுங்கள்.