ਇੱਕ ਡਿਵੈਲਪਰ ਨੇ ਪਾਇਆ ਕਿ Playwright ਜਾਂ Puppeteer ਰਾਹੀਂ Chrome DevTools debugger ਲਗਾਉਣ ਨਾਲ fetch-ਅਧਾਰਤ ਅੱਪਲੋਡਾਂ ਦੀ ਰਫ਼ਤਾਰ 20 ਗੁਣਾ ਤੋਂ ਵੀ ਵੱਧ ਘਟ ਜਾਂਦੀ ਹੈ, ਜਿਸ ਨਾਲ ਰੋਜ਼ਾਨਾ ਦੇ ਪਰਫਾਰਮੈਂਸ ਬੈਂਚਮਾਰਕ ਗਲਤ ਡੇਟਾ ਵਿੱਚ ਬਦਲ ਜਾਂਦੇ ਹਨ।

ਉਹ ਪਹੇਲੀ ਜਿਸ ਨੇ ਜਾਂਚ ਨੂੰ ਜਨਮ ਦਿੱਤਾ

Coffer, ਇੱਕ ਬ੍ਰਾਊਜ਼ਰ-ਅਧਾਰਤ ਫਾਈਲ ਸਟੋਰ ਹੈ ਜੋ ਸਰਵਰ ਨੂੰ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਡੇਟਾ ਨੂੰ ਐਨਕ੍ਰਿਪਟ ਕਰਦਾ ਹੈ, ਜੋ ਰੁਟੀਨ ਤੌਰ 'ਤੇ ਇੱਕ ਲੋਕਲ ਨੈੱਟਵਰਕ 'ਤੇ gigabit-class ਅੱਪਲੋਡ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਟੀਮ ਨੇ ਅੱਪਲੋਡ ਦੀ ਰਫ਼ਤਾਰ ਮਾਪੀ, ਤਾਂ ਉਨ੍ਹਾਂ ਨੇ ਇੱਕ ਅੰਤਰ ਦੇਖਿਆ: ਡਾਊਨਲੋਡ ਲਿੰਕ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵਰਤ ਰਹੇ ਸਨ, ਪਰ ਅੱਪਲੋਡ ਉਪਲਬਧ ਬੈਂਡਵਿਡਥ ਦੇ ਲਗਭਗ ਅੱਠਵੇਂ ਹਿੱਸੇ 'ਤੇ ਹੀ ਚੱਲ ਰਹੇ ਸਨ। ਇਸ ਅੰਤਰ ਕਾਰਨ ਕੋਡ ਵਿੱਚ ਤਿੰਨ ਵਾਰ ਬਦਲਾਅ ਕੀਤੇ ਗਏ ਪਰ ਕੋਈ ਫਰਕ ਨਹੀਂ ਪਿਆ, ਜਦੋਂ ਤੱਕ ਕਿ ਚੌਥੇ "ਫਿਕਸ" ਨੇ ਇੱਕ ਵੱਡੀ ਛਾਲ ਦਿਖਾਈ—ਪਰ ਡਿਬੱਗਰ ਹਟਾਉਣ 'ਤੇ ਇਹ ਫਿਰ ਤੋਂ ਗਾਇਬ ਹੋ ਗਈ।

ਟੀਮ ਨੇ ਪਹਿਲਾਂ ਕੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ

ਇੰਜੀਨੀਅਰਾਂ ਨੇ ਆਮ ਸ਼ੱਕੀ ਕਾਰਨਾਂ ਦੀ ਜਾਂਚ ਕੀਤੀ:

  • Chunk size – ਬਲਾਕ ਨੂੰ 16 MiB ਤੋਂ ਦੁੱਗਣਾ ਕਰਕੇ 32 MiB ਕਰਨ ਨਾਲ ਵੀ ਥਰੂਪੁੱਟ (throughput) ਵਿੱਚ ਕੋਈ ਬਦਲਾਅ ਨਹੀਂ ਆਇਆ।
  • Pipelining – ਮੌਜੂਦਾ ਅੱਪਲੋਡ ਦੇ ਨਾਲ ਅਗਲੇ ਬਲਾਕ ਦੀ ਐਨਕ੍ਰਿਪਸ਼ਨ ਨੂੰ ਇੱਕੋ ਸਮੇਂ ਚਲਾਉਣ ਨਾਲ ਸਿਰਫ਼ 13% ਦਾ ਫਾਇਦਾ ਹੋਇਆ, ਜੋ ਮਾਪ ਦੀ ਗਲਤੀ (measurement noise) ਤੋਂ ਵੱਖਰਾ ਨਹੀਂ ਲੱਗ ਰਿਹਾ ਸੀ।
  • Concurrency – ਕਈ ਅੱਪਲੋਡਾਂ ਨੂੰ ਇੱਕੋ ਸਮੇਂ (parallel) ਚਲਾਉਣ ਨਾਲ ਵੀ ਕੁੱਲ ਰਫ਼ਤਾਰ ਉਹੀ ਰਹੀ, ਜੋ ਇੱਕ ਗਲੋਬਲ ਸੀਲਿੰਗ (global ceiling) ਵੱਲ ਇਸ਼ਾਰਾ ਕਰ ਰਹੀ ਸੀ।

ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਬਦਲਾਅ 8× ਦੀ ਸੁਸਤੀ (slowdown) ਦੀ ਵਿਆਖਿਆ ਨਹੀਂ ਕਰ ਸਕਿਆ।

ਇੱਕ ਹੈਰਾਨੀਜਨਕ ਸਿੱਧਾ ਮੁਕਾਬਲਾ

ਸਮੱਸਿਆ ਦੀ ਪਛਾਣ ਕਰਨ ਲਈ, ਟੀਮ ਨੇ ਕਲਾਇੰਟ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ (client implementation) ਬਦਲ ਦਿੱਤੀ। .NET HttpClient ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਉਨ੍ਹਾਂ ਨੇ ਉਸੇ ਨੈੱਟਵਰਕ 'ਤੇ 700 Mbps ਰਿਕਾਰਡ ਕੀਤਾ; ਉਹੀ ਰਿਕਵੈਸਟ Chromium ਦੀ fetch() API ਤੋਂ 140 Mbps 'ਤੇ ਰੁਕ ਗਈ। ਇਸ ਵੱਡੇ ਅੰਤਰ ਨੇ ਬ੍ਰਾਊਜ਼ਰ ਦੇ ਨੈੱਟਵਰਕ ਸਟੈਕ ਨੂੰ ਦੋਸ਼ੀ ਦੱਸਿਆ—ਪਰ ਅਗਲੇ ਪ੍ਰਯੋਗ ਨੇ ਕੁਝ ਹੋਰ ਹੀ ਸਾਬਤ ਕਰ ਦਿੱਤਾ।

ਡਿਬੱਗਰ ਦੀ ਲੁਕੀ ਹੋਈ ਕੀਮਤ

Playwright ਅਤੇ Puppeteer, Chrome DevTools Protocol (CDP) ਰਾਹੀਂ Chrome ਨੂੰ ਚਲਾਉਂਦੇ ਹਨ। ਉਹ ਪ੍ਰੋਟੋਕੋਲ ਬ੍ਰਾਊਜ਼ਰ ਪ੍ਰੋਸੈਸ ਨਾਲ ਇੱਕ ਡਿਬੱਗਰ ਲਗਾਉਂਦਾ ਹੈ, ਜੋ ਨੈੱਟਵਰਕ ਇਵੈਂਟਸ, DOM ਸਨੈਪਸ਼ਾਟਸ ਅਤੇ ਕੰਸੋਲ ਲੌਗਸ ਨੂੰ ਦਿਖਾਉਂਦਾ ਹੈ। ਟੀਮ ਨੇ ਇੱਕ ਕੇਂਦਰਿਤ ਟੈਸਟ ਕੀਤਾ: ਇੱਕ fetch() ਕਾਲ ਜੋ Uint8Array ਪੇਲੋਡ ਭੇਜ ਰਹੀ ਸੀ, ਇੱਕ ਵਾਰ CDP ਡਿਬੱਗਰ ਲਗਾ ਕੇ ਅਤੇ ਇੱਕ ਵਾਰ ਬਿਨਾਂ ਲਗਾਏ।

  • Debugger attached: 113 Mbps

ਡਿਬੱਗਰ ਦੀ ਮੌਜੂਦਗੀ ਨੇ ਅੱਪਲੋਡ ਦੀ ਰਫ਼ਤਾਰ ਨੂੰ 20 × ਤੋਂ ਵੀ ਵੱਧ ਘਟਾ ਦਿੱਤਾ। ਇੱਕ ਆਮ Edge ਵਿੰਡੋ ਵਿੱਚ ਮੈਨੂਅਲ ਟੈਸਟ—ਬਿਨਾਂ ਕਿਸੇ ਡਿਬੱਗਰ ਦੇ—600 + Mbps ਤੱਕ ਪਹੁੰਚ ਗਿਆ, ਜਿਸ ਤੋਂ ਪੁਸ਼ਟੀ ਹੋਈ ਕਿ ਬ੍ਰਾਊਜ਼ਰ ਖੁਦ ਬਿਨਾਂ ਕਿਸੇ ਰੁਕਾਵਟ ਦੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਸੰਭਾਲ ਸਕਦਾ ਹੈ।

ਇੱਕ ਛੋਟਾ, ਅਸਲੀ ਸੁਧਾਰ

ਹਾਲਾਂਕਿ ਸੁਸਤੀ ਦਾ ਮੁੱਖ ਕਾਰਨ ਡਿਬੱਗਰ ਸੀ, ਫਿਰ ਵੀ ਟੀਮ ਨੇ ਇੱਕ ਅਸਲੀ ਆਪਟੀਮਾਈਜ਼ੇਸ਼ਨ (optimization) ਲੱਭ ਲਈ: ਰਿਕਵੈਸਟ ਬਾਡੀ ਨੂੰ Uint8Array ਤੋਂ Blob ਵਿੱਚ ਬਦਲਣ ਨਾਲ Chromium ਦੀ ਰਫ਼ਤਾਰ ਲਗਭਗ 30 % ਵਧ ਗਈ। ਇਹ ਇੱਕ ਲਾਭਦਾਇਕ ਬਦਲਾਅ ਹੈ, ਪਰ ਉਸ "ਚਮਤਕਾਰੀ" ਵਾਧੇ ਦੇ ਨੇੜੇ ਨਹੀਂ ਹੈ ਜਿਸਦੀ ਸ਼ੁਰੂ ਵਿੱਚ ਉਮੀਦ ਕੀਤੀ ਗਈ ਸੀ।

ਇਹ ਇੰਜੀਨੀਅਰਾਂ ਲਈ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ

  • ਔਜ਼ਾਰ ਝੂਠ ਬੋਲ ਸਕਦੇ ਹਨ। ਉਹ ਪਰਫਾਰਮੈਂਸ ਟੂਲ ਜੋ ਬ੍ਰਾਊਜ਼ਰਾਂ ਨੂੰ ਆਟੋਮੇਟ ਕਰਦੇ ਹਨ, ਉਹ ਖੁਦ ਮਾਪ ਦੀ ਪ੍ਰਕਿਰਿਆ ਦਾ ਹਿੱਸਾ ਹੁੰਦੇ ਹਨ।
  • ਅਸੰਭਵ ਲੱਗਣ ਵਾਲੇ ਬੈਂਚਮਾਰਕਾਂ ਦੀ ਜਾਂਚ ਕਰਨੀ ਜ਼ਰੂਰੀ ਹੈ। ਜੇਕਰ ਅੰਕ ਨੈੱਟਵਰਕ ਸਮਰੱਥਾ ਤੋਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਵੱਖਰੇ ਹਨ, ਤਾਂ ਮਾਪ ਦਾ ਵਾਤਾਵਰਣ (measurement environment) ਪਹਿਲਾ ਸ਼ੱਕੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
  • ਇੱਕ ਨਲ (null) ਨਤੀਜਾ ਵੀ ਕੀਮਤੀ ਹੈ। ਇਹ ਪੁਸ਼ਟੀ ਕਰਨਾ ਕਿ ਕਿਸੇ ਬਦਲਾਅ ਨਾਲ ਕੁਝ ਨਹੀਂ ਹੋ ਰਿਹਾ, ਫ਼ਜ਼ੂਲ ਦੀ ਮਿਹਨਤ ਨੂੰ ਰੋਕਦਾ ਹੈ।
  • ਮੈਨੂਅਲ ਕੰਟਰੋਲ ਸਸਤੀ ਬੀਮਾ (insurance) ਵਾਂਗ ਹਨ। ਇੱਕ ਸਾਧਾਰਨ ਬ੍ਰਾਊਜ਼ਰ ਵਿੰਡੋ ਵਿੱਚ ਉਹੀ ਕੰਮ ਚਲਾਉਣ ਨਾਲ ਲੁਕੀ ਹੋਈ ਇੰਸਟ੍ਰੂਮੈਂਟੇਸ਼ਨ ਓਵਰਹੈੱਡ (instrumentation overhead) ਦਾ ਪਤਾ ਲੱਗ ਸਕਦਾ ਹੈ।

ਉਲਟ ਪੱਖ: ਜਦੋਂ ਡਿਬੱਗਰਾਂ ਦੀ ਲੋੜ ਲਾਜ਼ਮੀ ਹੋਵੇ

ਡਿਬੱਗਰ ਪੇਜ ਦੇ ਵਿਵਹਾਰ, ਐਰਰ ਟ੍ਰੇਸ (error traces), ਅਤੇ ਨੈੱਟਵਰਕ ਟਾਈਮਲਾਈਨਾਂ ਦੀ ਜਾਣਕਾਰੀ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ ਜੋ ਹੋਰ ਤਰੀਕੇ ਨਾਲ ਪ੍ਰਾਪਤ ਨਹੀਂ ਕੀਤੀ ਜਾ ਸਕਦੀ। ਰੈਗਰੈਸ਼ਨ ਟੈਸਟਿੰਗ, ਸੁਰੱਖਿਆ ਆਡਿਟ, ਜਾਂ ਗੁੰਝਲਦਾਰ UI ਇੰਟਰੈਕਸ਼ਨਾਂ ਲਈ, CDP ਡਿਬੱਗਰ ਲਗਾਉਣਾ ਅਕਸਰ ਲਾਜ਼ਮੀ ਹੁੰਦਾ ਹੈ। ਮੁੱਖ ਗੱਲ ਇਹ ਹੈ ਕਿ ਫੰਕਸ਼ਨਲ ਟੈਸਟਿੰਗ ਨੂੰ ਸ਼ੁੱਧ ਪਰਫਾਰਮੈਂਸ ਮਾਪ ਤੋਂ ਵੱਖ ਰੱਖਿਆ ਜਾਵੇ, ਅਤੇ ਜਦੋਂ ਪਰਫਾਰਮੈਂਸ ਮਾਪਣਾ ਮੁੱਖ ਉਦੇਸ਼ ਹੋਵੇ ਤਾਂ ਡਿਬੱਗਰ ਨੂੰ ਬੰਦ ਕਰ ਦਿੱਤਾ ਜਾਵੇ।

ਸਿੱਖਿਆ (Takeaway): ਉਹ ਸਾਧਨ ਜੋ ਆਟੋਮੇਟਡ ਟੈਸਟਿੰਗ ਨੂੰ ਸੰਭਵ ਬਣਾਉਂਦੇ ਹਨ, ਉਹ ਪਰਫਾਰਮੈਂਸ ਵਿੱਚ ਵਿਗਾੜ ਪੈਦਾ ਕਰਨ ਦਾ ਸਭ ਤੋਂ ਵੱਡਾ ਸਰੋਤ ਵੀ ਬਣ ਸਕਦੇ ਹਨ। ਬ੍ਰਾਊਜ਼ਰ, ਨੈੱਟਵਰਕ, ਜਾਂ ਕੋਡ ਨੂੰ ਦੋਸ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਕੋਈ ਡਿਬੱਗਰ ਚੁੱਪਚਾਪ ਡੇਟਾ ਸਟ੍ਰੀਮ ਨੂੰ ਘਟਾ (throttle) ਤਾਂ ਨਹੀਂ ਰਿਹਾ।