Playwright లేదా Puppeteer ద్వారా Chrome DevTools debuggerను అనుసంధానించడం వల్ల fetch-ఆధారిత అప్‌లోడ్‌లు 20 రెట్లు కంటే ఎక్కువగా నెమ్మదిస్తాయని (throttle) ఒక డెవలపర్ కనుగొన్నారు, ఇది రోజువారీ పెర్ఫార్మెన్స్ బెంచ్‌మార్క్‌లను తప్పుదోవ పట్టించే డేటాగా మారుస్తుంది.

పరిశోధనకు దారితీసిన చిక్కుముడి

సర్వర్‌కు పంపే ముందు డేటాను ఎన్‌క్రిప్ట్ చేసే బ్రౌజర్-ఆధారిత ఫైల్ స్టోర్ అయిన Coffer, స్థానిక నెట్‌వర్క్ (local network) ద్వారా క్రమం తప్పకుండా గిగాబిట్-క్లాస్ అప్‌లోడ్‌లను పంపిస్తుంది. టీమ్ అప్‌లోడ్ వేగాలను కొలిచినప్పుడు, ఒక తేడాను గమనించారు: డౌన్‌లోడ్‌లు లింక్‌ను పూర్తిగా వాడుకుంటున్నాయి (saturated), కానీ అప్‌లోడ్‌లు అందుబాటులో ఉన్న బ్యాండ్‌విడ్త్‌లో సుమారు ఎనిమిది వంతుల వేగంతో మాత్రమే సాగుతున్నాయి. ఈ వ్యత్యాసం వల్ల మూడు సార్లు కోడ్ మార్పులు చేసినప్పటికీ ఫలితం లభించలేదు, నాలుగవ "ఫిక్స్" భారీ మార్పును చూపించినట్లు అనిపించినప్పటికీ, debuggerను తొలగించగానే అది మళ్ళీ పాత స్థితికి చేరుకుంది.

టీమ్ మొదటగా ప్రయత్నించినవి

ఇంజనీర్లు సాధారణంగా అనుమానించే అంశాలను పరిశీలించారు:

  • Chunk size – బ్లాక్‌ను 16 MiB నుండి 32 MiBకి రెట్టింపు చేసినా త్రూపుట్ (throughput) మారలేదు.
  • Pipelining – ప్రస్తుత అప్‌లోడ్‌తో పాటు తదుపరి బ్లాక్ యొక్క ఎన్‌క్రిప్షన్‌ను ఒకేసారి చేయడం వల్ల కేవలం 13% లాభం మాత్రమే లభించింది, ఇది కొలతలలో వచ్చే సాధారణ వ్యత్యాసాల (measurement noise) కంటే పెద్దది కాదు.
  • Concurrency – ఒకేసారి పలు అప్‌లోడ్‌లను పారలల్‌గా రన్ చేసినా మొత్తం వేగం ఒకే స్థాయిలో ఉంది, ఇది ఏదో ఒక గ్లోబల్ పరిమితి (global ceiling) ఉందని సూచిస్తోంది.

ఈ మార్పులలో ఏదీ ఆ 8× స్లోడౌన్‌కు కారణం కాలేదు.

ఆశ్చర్యపరిచే తలపడటం (head-to-head comparison)

సమస్యను గుర్తించడానికి, టీమ్ క్లయింట్ ఇంప్లిమెంటేషన్‌ను మార్చింది. అదే నెట్‌వర్క్‌లో .NET HttpClient ఉపయోగించి 700 Mbps వేగాన్ని నమోదు చేశారు; అదే రిక్వెస్ట్‌ను Chromium యొక్క fetch() API ద్వారా పంపినప్పుడు అది 140 Mbps వద్ద ఆగిపోయింది. ఈ భారీ వ్యత్యాసం బ్రౌజర్ యొక్క నెట్‌వర్క్ స్టాక్ (network stack) వల్లనే జరుగుతుందని అనుమానించారు—కానీ తదుపరి ప్రయోగం దానికి భిన్నంగా నిరూపించింది.

debugger యొక్క దాగి ఉన్న ఖర్చు

Playwright మరియు Puppeteer, Chrome DevTools Protocol (CDP) ద్వారా Chromeను నడిపిస్తాయి. ఆ ప్రోటోకాల్ బ్రౌజర్ ప్రాసెస్‌కు ఒక debuggerను అనుసంధానిస్తుంది, దీనివల్ల నెట్‌వర్క్ ఈవెంట్‌లు, DOM స్నాప్‌షాట్‌లు మరియు కన్సోల్ లాగ్‌లు అందుబాటులోకి వస్తాయి. టీమ్ ఒక ప్రత్యేక పరీక్షను నిర్వహించింది: Uint8Array పేలోడ్‌ను పంపే ఒక fetch() కాల్‌ను, ఒకసారి CDP debuggerతో మరియు మరొకసారి దాని లేకుండా పరీక్షించారు.

  • Debugger attached: 113 Mbps

debugger ఉండటం వల్ల అప్‌లోడ్ వేగం 20× కంటే ఎక్కువగా తగ్గింది. సాధారణ Edge విండోలో (debugger లేకుండా) చేసిన మాన్యువల్ టెస్ట్ 600+ Mbps వేగాన్ని చేరుకుంది, దీనివల్ల ఎటువంటి అడ్డంకులు లేనప్పుడు బ్రౌజర్ స్వయంగా ట్రాఫిక్‌ను హ్యాండిల్ చేయగలదని నిర్ధారితమైంది.

ఒక చిన్న, వాస్తవ మెరుగుదల

స్లోడౌన్‌కు ప్రధాన కారణం debugger అయినప్పటికీ, టీమ్ ఒక నిజమైన ఆప్టిమైజేషన్‌ను కనుగొంది: రిక్వెస్ట్ బాడీని Uint8Array నుండి Blobకి మార్చడం వల్ల Chromium వేగం సుమారు 30% పెరిగింది. ఇది ఉపయోగకరమైన మార్పు అయినప్పటికీ, మొదట ఆశించిన "అద్భుతమైన" పెరుగుదలకు ఇది చాలా దూరంగా ఉంది.

ఇంజనీర్లకు ఇది ఎందుకు ముఖ్యం

  • పరికరాలు (Instruments) తప్పుగా చూపించవచ్చు. బ్రౌజర్‌లను ఆటోమేట్ చేసే పెర్ఫార్మెన్స్ టూల్స్ కూడా కొలత ప్రక్రియలో భాగమే.
  • అసాధ్యంగా అనిపించే బెంచ్‌మార్క్‌లను సరిచూసుకోవాలి (sanity check). ఒకవేళ సంఖ్యలు నెట్‌వర్క్ సామర్థ్యం కంటే విపరీతంగా తక్కువగా ఉంటే, మొదట కొలిచే వాతావరణాన్ని (measurement environment) అనుమానించాలి.
  • ఫలితం లేకపోవడం కూడా విలువైనదే. ఒక మార్పు వల్ల ఎటువంటి తేడా రాదని నిర్ధారించుకోవడం వల్ల, లేని బగ్‌ల కోసం అనవసరంగా శ్రమించకుండా ఉండవచ్చు.
  • మాన్యువల్ కంట్రోల్స్ తక్కువ ఖర్చుతో కూడిన భద్రత. సాధారణ బ్రౌజర్ విండోలో అదే ఆపరేషన్‌ను రన్ చేయడం ద్వారా దాగి ఉన్న ఇన్‌స్ట్రుమెంటేషన్ ఓవర్‌హెడ్‌ను (instrumentation overhead) గుర్తించవచ్చు.

వ్యతిరేక వాదన: debuggerలు ఎప్పుడు అనివార్యమో

పేజీ ప్రవర్తన, ఎర్రర్ ట్రేస్‌లు మరియు నెట్‌వర్క్ టైమ్‌లైన్‌లను చూడటానికి debuggerలు అవసరం, ఇవి లేకపోతే అందుబాటులో ఉండవు. రిగ్రెషన్ టెస్టింగ్, సెక్యూరిటీ ఆడిట్‌లు లేదా సంక్లిష్టమైన UI ఇంటరాక్షన్‌ల కోసం CDP debuggerను అనుసంధానించడం తరచుగా తప్పనిసరి. ఫంక్షనల్ టెస్టింగ్‌ను మరియు పెర్ఫార్మెన్స్ మెజర్‌మెంట్‌ను వేరుగా ఉంచడం మరియు పెర్ఫార్మెన్స్ కొలత లక్ష్యం అయినప్పుడు debuggerను డిసేబుల్ చేయడం ముఖ్యం.

ముఖ్య గమనిక: ఆటోమేటెడ్ టెస్టింగ్‌ను సాధ్యం చేసే సాధనాలే పెర్ఫార్మెన్స్ వక్రీకరణకు (distortion) ప్రధాన కారణం కావచ్చు. బ్రౌజర్, నెట్‌వర్క్ లేదా కోడ్‌ను నిందించే ముందు, ఏదైనా debugger డేటా స్ట్రీమ్‌ను నిశ్శబ్దంగా నెమ్మదింపజేస్తోందేమో సరిచూసుకోండి.