Mkutubaji aligundua kuwa kuunganisha debugger ya Chrome DevTools kupitia Playwright au Puppeteer hupunguza kasi ya upakiaji (uploads) unaotegemea fetch kwa zaidi ya mara 20, na kufanya vipimo vya utendaji vya kila siku kuwa vya upotoshaji.

Kitendawili kilichochochea uchunguzi

Coffer, mfumo wa kuhifadhi faili unaotegemea kivinjari unaoficha siri za data (encrypts) kabla ya kuzituma kwenye seva, hupakia data kwa kasi ya gigabit kupitia mtandao wa ndani. Timu ilipopima kasi ya upakiaji, waliona pengo: kupakua (downloads) kulijaza uwezo wote wa kiunganishi, lakini kupakia (uploads) kulikuwa polepole sana, takriban sehemu moja ya eight ya upana wa bandari (bandwidth) uliopo. Tofauti hiyo ilisababisha mzunguko mitatu wa mabadiliko ya kodi ambayo hayakuleta mabadiliko yoyote, hadi "suluhisho" la nne lilipoonekana kuleta ongezeko kubwa—lakini lilipotea mara tu debugger ilipoondolewa.

Kile timu ilichojaribu kwanza

Wahandisi walitafuta washukiwa wa kawaida:

  • Ukubwa wa kipande (Chunk size) – Kuongeza ukubwa wa kipande kutoka 16 MiB hadi 32 MiB hakukubadilisha kasi ya upitishaji.
  • Pipelining – Kuunganisha ufungaji wa siri (encryption) wa kipande kinachofuata na upakiaji wa sasa kulileta ongezeko dogo la 13 %, ambalo halikuonekana kutofautiana na makosa ya vipimo (measurement noise).
  • Usimamizi wa kazi nyingi (Concurrency) – Kuendesha upakiaji kadhaa kwa wakati mmoja kulifikia kikomo cha kasi ileile, jambo linaloashiria kuwepo kwa kikomo cha jumla.

Hakuna kati ya mabadiliko haya yaliyoeleza kupungua kwa kasi mara 8.

Ulinganishi wa kushangaza wa moja kwa moja

Ili kutenga tatizo, timu ilibadilisha mfumo wa mteja (client implementation). Kwa kutumia .NET HttpClient, walirekodi 700 Mbps kwenye mtandao uleule; ombi lilelile lilipotolewa kutoka kwenye API ya fetch() ya Chromium, lilikwama kwenye 140 Mbps. Tofauti hiyo kubwa ilielekeza lawama kwenye mfumo wa mtandao wa kivinjari (browser's network stack)—hadi jaribio linalofuata lilipothibitisha tofauti.

Gharama iliyofichika ya debugger

Playwright na Puppeteer huendesha Chrome kupitia Chrome DevTools Protocol (CDP). Itifaki hiyo huunganisha debugger kwenye mchakato wa kivinjari, ikionyesha matukio ya mtandao, picha za DOM (DOM snapshots), na kumbukumbu za console. Timu ilifanya jaribio mahususi: wito wa fetch() unaotuma data ya Uint8Array, mara moja ukiwa na debugger ya CDP ikiunganishwa na mara nyingine bila hiyo.

  • Debugger ikiunganishwa: 113 Mbps

Uwepo wa debugger ulipunguza kasi ya upakiaji kwa zaidi ya mara 20. Jaribio la mwongozo katika dirisha la kawaida la Edge—bila debugger ikiunganishwa—lilifikia 600 + Mbps, likithibitisha kuwa kivinjari chenyewe kinaweza kuhimili trafiki hiyo kisipokuwa na vikwazo.

Maboresho madogo, ya kweli

Ingawa debugger ndiyo iliyosababisha sehemu kubwa ya kupungua kwa kasi, timu bado iligundua uboreshaji wa kweli: kubadilisha mwili wa ombi (request body) kutoka Uint8Array kwenda Blob kuliongeza kasi ya Chromium kwa takriban 30 %. Ni marekebisho muhimu, lakini haukukaribia ongezeko la "ajabu" lililotarajiwa hapo awali.

Kwa nini hii ni muhimu kwa wahandisi

  • Vifaa vya vipimo vinaweza kudanganya. Zana za utendaji zinazojiendesha kwenye vivinjari zenyewe ni sehemu ya mnyororo wa upimaji.
  • Vipimo vinavyoonekana kuwa haviwezekani vinastahili kuhakikiwa. Ikiwa namba zinatofautiana sana na uwezo wa mtandao, mazingira ya upimaji yanapaswa kuwa mshukiwa wa kwanza.
  • Matokeo yasiyo na kitu (null result) yana thamani. Kuthibitisha kuwa mabadiliko hayafanyi kitu kunazuia kutumia nguvu bure kutafuta hitilafu zisizopo (phantom bugs).
  • Udhibiti wa mwongozo ni bima rahisi. Kuendesha operesheni ileile katika dirisha la kawaida la kivinjari kunaweza kufichua mzigo wa ziada wa vifaa vya upimaji (instrumentation overhead).

Upande wa pili: wakati debuggers ni muhimu sana

Debuggers hutoa uwezo wa kuona tabia ya ukurasa, nyayo za makosa (error traces), na mfuatano wa muda wa mtandao ambao vinginevyo hauwezi kupatikana. Kwa ajili ya majaribio ya urejeo (regression testing), ukaguzi wa usalama, au mwingiliano tata wa UI, kuunganisha debugger ya CDP mara nyingi ni jambo lisiloweza kuepukika. Siri ni kutenganisha majaribio ya utendaji (functional testing) na upimaji wa utendaji wa raw, na kuzima debugger wakati lengo ni upimaji wa utendaji.

Funzo: Zana zinazofanya majaribio ya kiotomatiki yawezekane zinaweza pia kuwa chanzo kikubwa cha upotoshaji wa utendaji. Kabla ya kulaumu kivinjari, mtandao, au kodi, hakikisha kuwa hakuna debugger inayopunguza kasi ya mtiririko wa data kimyakimya.