एका डेव्हलपरला असे आढळले की Playwright किंवा Puppeteer द्वारे Chrome DevTools debugger जोडल्यामुळे fetch-आधारित अपलोड्सची गती २० पटीहून अधिकने मंदावते, ज्यामुळे दैनंदिन परफॉर्मन्स बेंचमार्क चुकीचा डेटा दर्शवू लागतात.

तपासाला सुरुवात करणारे कोडे

Coffer, हे एक ब्राउझर-आधारित फाईल स्टोअर आहे जे सर्व्हरवर डेटा पाठवण्यापूर्वी तो एन्क्रिप्ट करते आणि स्थानिक नेटवर्कवर नियमितपणे गिगाबिट-क्लास अपलोड्स पाठवते. जेव्हा टीमने अपलोड स्पीड मोजला, तेव्हा त्यांना एक तफावत दिसून आली: डाउनलोड्समुळे लिंक पूर्णपणे वापरली जात होती, परंतु अपलोड्स उपलब्ध बँडविड्थच्या केवळ एक-आठवाव्या भागात अत्यंत संथ गतीने होत होते. या तफावतीमुळे कोडमध्ये तीन वेळा बदल करण्यात आले, परंतु त्याचा कोणताही परिणाम झाला नाही, जोपर्यंत चौथ्या "फिक्स"मुळे मोठी सुधारणा झाल्यासारखी वाटली—परंतु debugger काढताच ती सुधारणा नाहीशी झाली.

टीमने प्रथम काय प्रयत्न केले

इंजिनिअर्सनी नेहमीच्या संशयितांचा शोध घेतला:

  • Chunk size – ब्लॉकचा आकार 16 MiB वरून 32 MiB पर्यंत दुप्पट केल्यावरही थ्रूपुटमध्ये कोणताही बदल झाला नाही.
  • Pipelining – सध्याच्या अपलोडसोबतच पुढच्या ब्लॉकचे एन्क्रिप्शन सुरू केल्यामुळे केवळ १३% वाढ झाली, जी मोजमापातील त्रुटी (measurement noise) मानली जाऊ शकते.
  • Concurrency – एकाच वेळी अनेक अपलोड्स चालवल्या तरी एकूण वेग मर्यादित राहिला, ज्यावरून असे सूचित होते की काहीतरी जागतिक मर्यादा (global ceiling) आहे.

यापैकी कोणत्याही बदलामुळे ८ पटीने होणारा मंदाव स्पष्ट होत नव्हता.

एक आश्चर्यकारक थेट तुलना

समस्येचे मूळ शोधण्यासाठी, टीमने क्लायंट इम्प्लिमेंटेशन बदलले. .NET HttpClient वापरून त्यांनी त्याच नेटवर्कवर 700 Mbps वेग नोंदवला; मात्र Chromium च्या fetch() API मधून पाठवलेल्या त्याच विनंतीचा वेग 140 Mbps वर येऊन थांबला. या टोकाच्या फरकामुळे ब्राउझरचा नेटवर्क स्टॅक दोषी असल्याचे वाटले—जोपर्यंत पुढच्या प्रयोगाने याच्या उलट सिद्ध केले नाही.

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) खोटे बोलू शकतात. ब्राउझर ऑटोमेट करणारे परफॉर्मन्स टूल्स स्वतः मोजमाप प्रक्रियेचा एक भाग असतात.
  • अशक्य वाटणाऱ्या बेंचमार्कची पडताळणी करणे आवश्यक आहे. जर आकडेवारी नेटवर्क क्षमतेपेक्षा खूपच वेगळी असेल, तर मोजमाप करणारे वातावरण (measurement environment) हा पहिला संशयित असावा.
  • शून्य निकाल (Null result) देखील मौल्यवान असतो. एखादा बदल काहीही परिणाम करत नाही हे समजल्यामुळे काल्पनिक बग्सच्या (phantom bugs) मागे लागण्याचा वेळ वाचतो.
  • मॅन्युअल नियंत्रण हे स्वस्त विमा आहे. साध्या ब्राउझर विंडोमध्ये तीच प्रक्रिया चालवून तुम्ही छुपे इन्स्ट्रुमेंटेशन ओव्हरहेड (instrumentation overhead) शोधू शकता.

प्रतिवाद: जेव्हा debuggers अपरिहार्य असतात

Debuggers मुळे पेजचे वर्तन, एरर ट्रेसेस आणि नेटवर्क टाइमलाईन्सची माहिती मिळते जी अन्यथा उपलब्ध नसते. रिग्रेशन टेस्टिंग, सुरक्षा ऑडिट किंवा जटिल UI इंटरॅक्शन्ससाठी, CDP debugger जोडणे अनेकदा अनिवार्य असते. मुख्य गोष्ट म्हणजे फंक्शनल टेस्टिंग आणि रॉ परफॉर्मन्स मोजमाप या दोन गोष्टी वेगळ्या ठेवणे, आणि जेव्हा परफॉर्मन्स मोजमाप हे मुख्य ध्येय असेल, तेव्हा debugger बंद ठेवणे.

निष्कर्ष (Takeaway): ऑटोमेटेड टेस्टिंग शक्य करणारी साधनेच परफॉर्मन्समध्ये विरूपण (distortion) निर्माण करण्याचा सर्वात मोठा स्रोत बनू शकतात. ब्राउझर, नेटवर्क किंवा कोडला दोष देण्यापूर्वी, कोणताही debugger डेटा स्ट्रीमची गती चोरून कमी (throttling) करत नाही ना, याची खात्री करून घ्या.