Playwright ಅಥವಾ Puppeteer ಮೂಲಕ Chrome DevTools debugger ಅನ್ನು ಅಳವಡಿಸುವುದರಿಂದ fetch-ಆಧಾರಿತ ಅಪ್‌ಲೋಡ್‌ಗಳು 20 ಪಟ್ಟು ಹೆಚ್ಚು ನಿಧಾನವಾಗುತ್ತವೆ (throttle ಆಗುತ್ತವೆ) ಎಂದು ಒಬ್ಬ ಡೆವಲಪರ್ ಪತ್ತೆಹಚ್ಚಿದ್ದಾರೆ, ಇದು ದೈನಂದಿನ ಪರ್ಫಾರ್ಮೆನ್ಸ್ ಬೆಂಚ್‌ಮಾರ್ಕ್‌ಗಳನ್ನು ತಪ್ಪಾದ ದತ್ತಾಂಶವನ್ನಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ.

ತನಿಖೆಗೆ ಪ್ರೇರಣೆ ನೀಡಿದ ಒಗಟು

Coffer ಎಂಬುದು ಬ್ರೌಸರ್ ಆಧಾರಿತ ಫೈಲ್ ಸ್ಟೋರ್ ಆಗಿದ್ದು, ಇದು ಡೇಟಾವನ್ನು ಸರ್ವರ್‌ಗೆ ಕಳುಹಿಸುವ ಮೊದಲು ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಸ್ಥಳೀಯ ನೆಟ್‌ವರ್ಕ್ ಮೂಲಕ ಗಿಗಾಬಿಟ್-ತರದ ಅಪ್‌ಲೋಡ್‌ಗಳನ್ನು ನಿಯಮಿತವಾಗಿ ಮಾಡುತ್ತದೆ. ತಂಡವು ಅಪ್‌ಲೋಡ್ ವೇಗವನ್ನು ಅಳೆಯುವಾಗ, ಒಂದು ವ್ಯತ್ಯಾಸವನ್ನು ಕಂಡಿತು: ಡೌನ್‌ಲೋಡ್‌ಗಳು ಸಂಪೂರ್ಣ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಅನ್ನು ಬಳಸಿಕೊಳ್ಳುತ್ತಿದ್ದವು, ಆದರೆ ಅಪ್‌ಲೋಡ್‌ಗಳು ಲಭ್ಯವಿರುವ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್‌ನប្រហೇಚ್ಚುವ ಒಂದು ಎಂಟನೇ ಭಾಗದ ವೇಗದಲ್ಲಿ ಸಾಗುತ್ತಿದ್ದವು. ಈ ವ್ಯತ್ಯಾಸವು ಮೂರು ಸುತ್ತಿನ ಕೋಡ್ ಬದಲಾವಣೆಗಳಿಗೆ ಕಾರಣವಾಯಿತು, ಆದರೆ ಅವು ಯಾವುದೇ ಪ್ರಯೋಜನ ನೀಡಲಿಲ್ಲ. ನಾಲ್ಕನೇ "ಫಿಕ್ಸ್" (fix) ದೊಡ್ಡ ಮಟ್ಟದ ವೇಗವನ್ನು ನೀಡಿದಂತೆ ಕಂಡಿತು—ಆದರೆ debugger ಅನ್ನು ತೆಗೆದುಹಾಕಿದಾಗ ಅದು ಮಾಯವಾಯಿತು.

ತಂಡವು ಮೊದಲು ಪ್ರಯತ್ನಿಸಿದವುಗಳು

ಇಂಜಿನಿಯರ್‌ಗಳು ಸಾಮಾನ್ಯ ಸಂಶಯಿತರನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಪ್ರಯತ್ನಿಸಿದರು:

  • Chunk size – ಬ್ಲಾಕ್ ಅನ್ನು 16 MiB ನಿಂದ 32 MiB ಗೆ ದ್ವಿಗುಣಗೊಳಿಸಿದರೂ, ಥ್ರೂಪುಟ್ (throughput) ಬದಲಾಗಲಿಲ್ಲ.
  • Pipelining – ಪ್ರಸ್ತುತ ಅಪ್‌ಲೋಡ್‌ನೊಂದಿಗೆ ಮುಂದಿನ ಬ್ಲಾಕ್‌ನ ಎನ್‌ಕ್ರಿಪ್ಶನ್ ಅನ್ನು ಒಟ್ಟಿಗೆ ಮಾಡುವುದರಿಂದ ಕೇವಲ 13% ಲಾಭವಾಯಿತು, ಇದು ಅಳತೆಯ ವ್ಯತ್ಯಾಸಕ್ಕಿಂತ (measurement noise) ಭಿನ್ನವಾಗಿರಲಿಲ್ಲ.
  • Concurrency – ಹಲವಾರು ಅಪ್‌ಲೋಡ್‌ಗಳನ್ನು ಸಮಾಂತರವಾಗಿ (parallel) ಚಲಾಯಿಸುವುದು ಒಟ್ಟು ವೇಗವನ್ನು ಒಂದೇ ಮಟ್ಟದಲ್ಲಿ ತಡೆಯಿತು, ಇದು ಯಾವುದೋ ಒಂದು ಗ್ಲೋಬಲ್ ಮಿತಿಯನ್ನು ಸೂಚಿಸುತ್ತಿತ್ತು.

ಈ ಯಾವುದೇ ಬದಲಾವಣೆಗಳು 8× ವೇಗ ಕುಸಿತವನ್ನು ವಿವರಿಸಲಿಲ್ಲ.

ಆಶ್ಚರ್ಯಕರವಾದ ನೇರ ಹೋಲಿಕೆ

ಸಮಸ್ಯೆಯನ್ನು ಪ್ರತ್ಯೇಕಿಸಲು, ತಂಡವು ಕ್ಲೈಂಟ್ ಇಂಪ್ಲಿಮೆಂಟೇಶನ್ ಅನ್ನು ಬದಲಾಯಿಸಿತು. .NET HttpClient ಬಳಸಿ ಅದೇ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಅವರು 700 Mbps ಅನ್ನು ದಾಖಲಿಸಿದರು; ಅದೇ ವಿನಂತಿಯನ್ನು (request) Chromium ನ fetch() API ಮೂಲಕ ಮಾಡಿದಾಗ ಅದು 140 Mbps ನಲ್ಲಿ ನಿಂತುಹೋಯಿತು. ಈ ತೀವ್ರ ವ್ಯತ್ಯಾಸವು ಬ್ರೌಸರ್‌ನ ನೆಟ್‌ವರ್ಕ್ ಸ್ಟ್ಯಾಕ್ ಅನ್ನು culprit (ಕಾರಣ) ಎಂದು ತೋರಿಸಿಕೊಟ್ಟಿತು—ಆದರೆ ಮುಂದಿನ ಪ್ರಯೋಗವು ಇದನ್ನು ಸುಳ್ಳು ಎಂದು ಸಾಬೀತುಪಡಿಸಿತು.

debugger ನ ಅಡಗಿರುವ ವೆಚ್ಚ

Playwright ಮತ್ತು Puppeteer ಗಳು Chrome DevTools Protocol (CDP) ಮೂಲಕ Chrome ಅನ್ನು ನಿಯಂತ್ರಿಸುತ್ತವೆ. ಆ ಪ್ರೊಟೊಕಾಲ್ ಬ್ರೌಸರ್ ಪ್ರಕ್ರಿಯೆಗೆ debugger ಅನ್ನು ಅಳವಡಿಸುತ್ತದೆ, ಇದು ನೆಟ್‌ವರ್ಕ್ ಇವೆಂಟ್‌ಗಳು, DOM ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ಗಳು ಮತ್ತು ಕನ್ಸೋಲ್ ಲಾಗ್‌ಗಳನ್ನು ಪ್ರದರ್ಶಿಸುತ್ತದೆ. ತಂಡವು ಒಂದು ನಿರ್ದಿಷ್ಟ ಪರೀಕ್ಷೆಯನ್ನು ನಡೆಸಿತು: ಒಂದು fetch() ಕರೆಯ ಮೂಲಕ Uint8Array ಪೇಲೋಡ್ ಅನ್ನು ಕಳುಹಿಸುವುದು, ಒಮ್ಮೆ CDP debugger ಅಳವಡಿಸಿದಾಗ ಮತ್ತು ಒಮ್ಮೆ ಇಲ್ಲದಿದ್ದಾಗ.

  • Debugger ಅಳವಡಿಸಿದಾಗ: 113 Mbps

Debugger ಇರುವುದರಿಂದ ಅಪ್‌ಲೋಡ್ ವೇಗವು 20 × ಕ್ಕಿಂತ ಹೆಚ್ಚು ಕಡಿಮೆಯಾಯಿತು. ಯಾವುದೇ debugger ಇಲ್ಲದ ಸಾಮಾನ್ಯ Edge ವಿಂಡೋದಲ್ಲಿ ನಡೆಸಿದ ಮ್ಯಾನುಯಲ್ ಪರೀಕ್ಷೆಯು 600 + Mbps ತಲುಪಿತು, ಇದು ಬ್ರೌಸರ್ ಯಾವುದೇ ಅಡೆತಡೆಯಿಲ್ಲದೆ ಟ್ರಾಫಿಕ್ ಅನ್ನು ನಿಭಾಯಿಸಬಲ್ಲದು ಎಂಬುದನ್ನು ಖಚಿತಪಡಿಸಿತು.

ಒಂದು ಸಣ್ಣ, ನೈಜ ಸುಧಾರಣೆ

ವೇಗ ಕುಸಿತಕ್ಕೆ debugger ಪ್ರಮುಖ ಕಾರಣವಾಗಿದ್ದರೂ, ತಂಡವು ಒಂದು ನೈಜ ಆಪ್ಟಿಮೈಸೇಶನ್ ಅನ್ನು ಪತ್ತೆಹಚ್ಚಿತು: ರಿಕ್ವೆಸ್ಟ್ ಬಾಡಿಯನ್ನು (request body) Uint8Array ನಿಂದ Blob ಗೆ ಬದಲಾಯಿಸುವುದರಿಂದ Chromium ನ ವೇಗವು ಸುಮಾರು 30 % ಹೆಚ್ಚಾಯಿತು. ಇದು ಉಪಯುಕ್ತ ಬದಲಾವಣೆಯಾಗಿದ್ದರೂ, ಮೂಲತಃ ನಿರೀಕ್ಷಿಸಿದ "ಅದ್ಭುತ" ವೇಗದ ಹೆಚ್ಚಳಕ್ಕೆ ಇದು ಸಮನಲ್ಲ.

ಇದು ಇಂಜಿನಿಯರ್‌ಗಳಿಗೆ ಏಕೆ ಮುಖ್ಯ

  • ಉಪಕರಣಗಳು ಸುಳ್ಳು ಹೇಳಬಹುದು. ಬ್ರೌಸರ್‌ಗಳನ್ನು ಆಟೊಮೇಷನ್ ಮಾಡುವ ಪರ್ಫಾರ್ಮೆನ್ಸ್ ಟೂಲ್‌ಗಳು ಕೂಡ ಅಳತೆಯ ಪ್ರಕ್ರಿಯೆಯ ಒಂದು ಭಾಗವಾಗಿರುತ್ತವೆ.
  • ಅಸಾಧ್ಯವೆಂದು ತೋರುವ ಬೆಂಚ್‌ಮಾರ್ಕ್‌ಗಳನ್ನು ಮರುಪರಿಶೀಲಿಸಬೇಕು. ಅಂಕಿಅಂಶಗಳು ನೆಟ್‌ವರ್ಕ್ ಸಾಮರ್ಥ್ಯಕ್ಕಿಂತ ವಿಪರೀತ ವ್ಯತ್ಯಾಸದಲ್ಲಿದ್ದರೆ, ಅಳತೆಯ ಪರಿಸರವೇ (measurement environment) ಮೊದಲ ಶಂಕಿತವಾಗಿದ್ದೀತು.
  • ಯಾವುದೇ ಫಲಿತಾಂಶ ಬರದಿದ್ದರೂ ಅದು ಅಮೂಲ್ಯ. ಒಂದು ಬದಲಾವಣೆಯಿಂದ ಯಾವುದೇ ವ್ಯತ್ಯಾಸವಾಗುವುದಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವುದು, ಇಲ್ಲದ ಬಗ್‌ಗಳ (phantom bugs) ಹಿಂದೆ ಸಮಯ ವ್ಯರ್ಥ ಮಾಡುವುದನ್ನು ತಪ್ಪಿಸುತ್ತದೆ.
  • ಮ್ಯಾನುಯಲ್ ನಿಯಂತ್ರಣಗಳು ಉತ್ತಮ ವಿಮೆ ಇದ್ದಂತೆ. ಸಾಮಾನ್ಯ ಬ್ರೌಸರ್ ವಿಂಡೋದಲ್ಲಿ ಅದೇ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಮಾಡುವುದರಿಂದ ಅಡಗಿರುವ ಇನ್ಸ್ಟ್ರುಮೆಂಟೇಶನ್ ಓವರ್‌ಹೆಡ್ (instrumentation overhead) ಅನ್ನು ಪತ್ತೆಹಚ್ಚಬಹುದು.

ವಿರೋಧಾತ್ಮಕ ಅಂಶ: debugger ಗಳು ಅತ್ಯಗತ್ಯವಾಗಿದ್ದಾಗ

Debugger ಗಳು ಪೇಜ್ ವರ್ತನೆ, ಎರರ್ ಟ್ರೇಸ್‌ಗಳು ಮತ್ತು ನೆಟ್‌ವರ್ಕ್ ಟೈಮ್‌ಲೈನ್‌ಗಳ ಬಗ್ಗೆ ಮಾಹಿತಿ ನೀಡುತ್ತವೆ, ಇವುಗಳನ್ನು ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಪಡೆಯಲು ಸಾಧ್ಯವಿಲ್ಲ. ರಿಗ್ರೆಷನ್ ಟೆಸ್ಟಿಂಗ್, ಸೆಕ್ಯೂರಿಟಿ ಆಡಿಟ್ ಅಥವಾ ಸಂಕೀರ್ಣ UI ಇಂಟರಾಕ್ಷನ್‌ಗಳಿಗಾಗಿ, CDP debugger ಅನ್ನು ಅಳವಡಿಸುವುದು ಅನಿವಾರ್ಯವಾಗಿರುತ್ತದೆ. ಪ್ರಮುಖ ವಿಷಯವೆಂದರೆ ಫಂಕ್ಷನಲ್ ಟೆಸ್ಟಿಂಗ್ ಅನ್ನು ಪರ್ಫಾರ್ಮೆನ್ಸ್ ಅಳತೆಯಿಂದ ಪ್ರತ್ಯೇಕಿಸುವುದು ಮತ್ತು ಪರ್ಫಾರ್ಮೆನ್ಸ್ ಅಳತೆಯೇ ಗುರಿಯಾಗಿದ್ದಾಗ debugger ಅನ್ನು ಡಿಸೇಬಲ್ ಮಾಡುವುದು.

ಸಾರಾಂಶ: ಆಟೊಮೇಷನ್ ಟೆಸ್ಟಿಂಗ್ ಅನ್ನು ಸಾಧ್ಯವಾಗಿಸುವ ಪರಿಕರಗಳೇ ಪರ್ಫಾರ್ಮೆನ್ಸ್ ವಿರೂಪಕ್ಕೆ (performance distortion) ದೊಡ್ಡ ಕಾರಣವಾಗಬಹುದು. ಬ್ರೌಸರ್, ನೆಟ್‌ವರ್ಕ್ ಅಥವಾ ಕೋಡ್ ಅನ್ನು ದೂಷಿಸುವ ಮೊದಲು, ಯಾವುದೇ debugger ಡೇಟಾ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಮೌನವಾಗಿ ತಡೆಹಿಡಿಯುತ್ತಿಲ್ಲ ಎಂಬುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ.