એક ડેવલપરે શોધી કાઢ્યું કે Playwright અથવા Puppeteer દ્વારા Chrome DevTools debugger જોડવાથી fetch-આધારિત અપલોડ્સ 20 ગણાથી વધુ ધીમા પડી જાય છે, જેનાથી રોજિંદા પર્ફોર્મન્સ બેન્ચમાર્ક ભ્રામક ડેટામાં ફેરવાઈ જાય છે.

તપાસને ઉત્તેજિત કરનાર કોયડો

Coffer, એક બ્રાઉઝર-આધારિત ફાઇલ સ્ટોર છે જે સર્વર પર મોકલતા પહેલા ડેટાને એન્ક્રિપ્ટ કરે છે, તે નિયમિતપણે લોકલ નેટવર્ક પર ગીગાબીટ-ક્લાસ અપલોડ્સ મોકલે છે. જ્યારે ટીમે અપલોડ સ્પીડ માપી, ત્યારે તેમને એક તફાવત જોવા મળ્યો: ડાઉનલોડ્સ લિંકનો પૂરેપૂરો ઉપયોગ કરી રહ્યા હતા, પરંતુ અપલોડ્સ ઉપલબ્ધ બેન્ડવિડ્થના અંદાજે આઠમાં ભાગની ઝડપે ચાલી રહ્યા હતા. આ વિસંગતતાને કારણે કોડમાં ત્રણ વખત ફેરફાર કરવામાં આવ્યા જે કોઈ ખાસ પરિણામ લાવવામાં નિષ્ફળ રહ્યા, ત્યાં સુધી કે ચોથા "ફિક્સ" થી મોટો ઉછાળો જોવા મળ્યો—પરંતુ ડિબગરને દૂર કરતા તે ફરીથી અદૃશ્ય થઈ ગયો.

ટીમે સૌ પ્રથમ શું પ્રયાસ કર્યો

એન્જિનિયરોએ સામાન્ય શંકાસ્પદો પર ધ્યાન આપ્યું:

  • Chunk size – બ્લોકને 16 MiB થી વધારીને 32 MiB કરવાથી થ્રુપુટમાં કોઈ ફેરફાર થયો નહીં.
  • Pipelining – વર્તમાન અપલોડ સાથે આગામી બ્લોકના એન્ક્રિપ્શનને ઓવરલેપ કરવાથી માત્ર 13% નો સામાન્ય વધારો થયો, જે માપન દરમિયાન થતા સામાન્ય ફેરફારો (noise) થી અલગ કરી શકાય તેમ નહોતો.
  • Concurrency – સમાંતર રીતે (parallel) અનેક અપલોડ્સ ચલાવવાથી પણ કુલ સ્પીડ સમાન જ રહી, જે સૂચવે છે કે કોઈ વૈશ્વિક મર્યાદા (global ceiling) છે.

આમાંથી કોઈ પણ ફેરફાર 8× સ્લોડાઉનનું કારણ સમજાવી શક્યા નહીં.

એક આશ્ચર્યજનક સામસામેની સરખામણી

સમસ્યાને અલગ તારવવા માટે, ટીમે ક્લાયન્ટ ઇમ્પ્લીમેન્ટેશન બદલી નાખ્યું. .NET HttpClient નો ઉપયોગ કરીને તેઓએ તે જ નેટવર્ક પર 700 Mbps નોંધ્યા; જ્યારે Chromium ના fetch() API દ્વારા કરવામાં આવેલી સમાન વિનંતી (request) 140 Mbps પર અટકી ગઈ. આ તફાવતે બ્રાઉઝરના નેટવર્ક સ્ટેકને દોષિત ગણાવ્યો—જ્યાં સુધી પછીના પ્રયોગે તેને ખોટું સાબિત ન કર્યું.

ડિબગરમાં છુપાયેલી કિંમત

Playwright અને Puppeteer, Chrome DevTools Protocol (CDP) દ્વારા Chrome ને ચલાવે છે. તે પ્રોટોકોલ બ્રાઉઝર પ્રોસેસ સાથે ડિબગર જોડે છે, જેનાથી નેટવર્ક ઇવેન્ટ્સ, DOM સ્નેપશોટ્સ અને કન્સોલ લોગ્સ ખુલ્લા પડે છે. ટીમે એક લક્ષિત પરીક્ષણ કર્યું: એક fetch() કોલ જે Uint8Array પેલોડ મોકલે છે, એકવાર CDP ડિબગર સાથે અને એકવાર તેના વગર.

  • Debugger attached: 113 Mbps

ડિબગરની હાજરીએ અપલોડ સ્પીડને 20 × થી વધુ ઘટાડી દીધી. એક સામાન્ય Edge વિન્ડોમાં મેન્યુઅલ ટેસ્ટ—ડિબગર વગર—600 + Mbps સુધી પહોંચ્યો, જે પુષ્ટિ કરે છે કે જ્યારે કોઈ અવરોધ ન હોય ત્યારે બ્રાઉઝર પોતે ટ્રાફિક હેન્ડલ કરી શકે છે.

એક નાનો, વાસ્તવિક સુધારો

જોકે સ્લોડાઉનનું મુખ્ય કારણ ડિબગર હતું, તેમ છતાં ટીમે એક સાચું ઓપ્ટિમાઇઝેશન શોધી કાઢ્યું: રિક્વેસ્ટ બોડીને Uint8Array થી બદલીને Blob કરવાથી Chromium ની સ્પીડ અંદાજે 30 % વધી ગઈ. તે એક ઉપયોગી ફેરફાર છે, પરંતુ જે "ચમત્કારિક" વધારાની અપેક્ષા રાખવામાં આવી હતી તેની પાસે તે પહોંચતો નથી.

એન્જિનિયરો માટે આ શા માટે મહત્વનું છે

  • સાધનો (Instruments) જૂઠું બોલી શકે છે. બ્રાઉઝરને ઓટોમેટ કરી શકતા પર્ફોર્મન્સ ટૂલ્સ પોતે જ માપન સાંકળનો ભાગ છે.
  • અશક્ય લાગતા બેન્ચમાર્ક માટે સેનિટી ચેક (sanity check) જરૂરી છે. જો આંકડા નેટવર્ક ક્ષમતાથી ખૂબ જ અલગ હોય, તો માપન વાતાવરણ (measurement environment) પ્રથમ શંકાસ્પદ હોવું જોઈએ.
  • શૂન્ય પરિણામ પણ મૂલ્યવાન છે. કોઈ ફેરફારથી કંઈ જ થતું નથી તેની પુષ્ટિ કરવાથી કાલ્પનિક બગ્સ (phantom bugs) પાછળનો બિનજરૂરી પ્રયાસ બચી જાય છે.
  • મેન્યુઅલ કંટ્રોલ સસ્તો વીમો છે. સાદા બ્રાઉઝર વિન્ડોમાં સમાન કામગીરી ચલાવવાથી છુપાયેલ ઇન્સ્ટ્રુમેન્ટેશન ઓવરહેડ (instrumentation overhead) જાણી શકાય છે.

વિરોધ પક્ષ: જ્યારે ડિબગર્સ અનિવાર્ય હોય

ડિબગર્સ પેજ વર્તણૂક, એરર ટ્રેસ અને નેટવર્ક ટાઈમલાઈન વિશે એવી વિઝિબિલિટી આપે છે જે અન્યથા અપ્રાપ્ય હોય છે. રિગ્રેશન ટેસ્ટિંગ, સિક્યુરિટી ઓડિટ અથવા જટિલ UI ઇન્ટરેક્શન માટે, CDP ડિબગર જોડવો ઘણીવાર અનિવાર્ય હોય છે. મુખ્ય વાત એ છે કે ફંક્શનલ ટેસ્ટિંગને કાચા પર્ફોર્મન્સ માપનથી અલગ રાખવું, અને જ્યારે પર્ફોર્મન્સ માપન લક્ષ્ય હોય ત્યારે ડિબગરને ડિસેબલ કરવું.

મુખ્ય વાત (Takeaway): જે સાધનો ઓટોમેટેડ ટેસ્ટિંગ શક્ય બનાવે છે તે પર્ફોર્મન્સ વિરૂપણ (performance distortion) ના સૌથી મોટા સ્ત્રોત પણ બની શકે છે. બ્રાઉઝર, નેટવર્ક અથવા કોડને દોષ આપતા પહેલા, ખાતરી કરો કે કોઈ ડિબગર ડેટા સ્ટ્રીમને છૂપી રીતે ધીમી તો નથી કરી રહ્યો ને.