ایک ڈویلپر نے دریافت کیا کہ Playwright یا Puppeteer کے ذریعے Chrome DevTools debugger منسلک کرنے سے fetch-based uploads کی رفتار 20 گنا سے زیادہ کم ہو جاتی ہے، جس سے روزمرہ کے پرفارمنس بینچ مارکس گمراہ کن ڈیٹا میں بدل جاتے ہیں۔

وہ معمہ جس نے تحقیقات کو جنم دیا

Coffer، ایک براؤزر پر مبنی فائل اسٹور ہے جو سرور پر بھیجنے سے پہلے ڈیٹا کو انکرپٹ کرتا ہے، عام طور پر لوکل نیٹ ورک پر گیگا بٹ کلاس اپ لوڈز بھیجتا ہے۔ جب ٹیم نے اپ لوڈ کی رفتار کی پیمائش کی، تو انہیں ایک فرق نظر آیا: ڈاؤن لوڈز لنک کو مکمل طور پر استعمال کر رہے تھے، لیکن اپ لوڈز دستیاب بینڈوتھ کے تقریباً آٹھویں حصے کی رفتار سے چل رہے تھے۔ اس فرق کی وجہ سے کوڈ میں تبدیلی کے تین چکر لگائے گئے جو ناکام رہے، یہاں تک کہ چوتھی "اصلاح" سے ایک بہت بڑا اضافہ نظر آیا—لیکن ڈیبگر (debugger) ہٹاتے ہی وہ بھی غائب ہو گیا۔

ٹیم نے سب سے پہلے کیا آزمایا

انجینئرز نے عام مشکوک وجوہات پر غور کیا:

  • Chunk size – بلاک کو 16 MiB سے بڑھا کر 32 MiB کرنے سے تھرو پٹ (throughput) میں کوئی تبدیلی نہیں آئی۔
  • Pipelining – موجودہ اپ لوڈ کے ساتھ اگلے بلاک کی انکرپشن کو ہم آہنگ کرنے سے صرف 13% کا معمولی اضافہ ہوا، جسے پیمائش کے شور (measurement noise) سے الگ کرنا مشکل تھا۔
  • Concurrency – کئی اپ لوڈز کو متوازی (parallel) چلانے سے بھی کل رفتار ایک ہی حد پر رک گئی، جس سے ظاہر ہوا کہ کوئی عالمی حد (global ceiling) موجود ہے۔

ان میں سے کوئی بھی تبدیلی 8 گنا کی اس سست رفتاری کی وضاحت نہیں کر سکی۔

ایک حیران کن آمنے سامنے کا موازنہ

مسلے کی نشاندہی کے لیے، ٹیم نے کلائنٹ امپلیمنٹیشن کو تبدیل کیا۔ .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 تک پہنچ گیا، جس سے تصدیق ہوئی کہ جب براؤزر پر کوئی بوجھ نہ ہو تو وہ ٹریفک کو سنبھال سکتا ہے۔

ایک معمولی، حقیقی بہتری

اگرچہ سست رفتاری کی بڑی وجہ ڈیبگر ہی تھا، لیکن ٹیم نے ایک حقیقی آپٹیمائزیشن بھی دریافت کی: ریکوئسٹ باڈی کو Uint8Array سے Blob میں تبدیل کرنے سے Chromium کی رفتار میں تقریباً 30% کا اضافہ ہوا۔ یہ ایک مفید تبدیلی ہے، لیکن اس "معجزاتی" اضافے کے قریب بھی نہیں ہے جس کی اصل میں امید کی گئی تھی۔

یہ انجینئرز کے لیے کیوں اہم ہے

  • آلات جھوٹ بول سکتے ہیں۔ وہ پرفارمنس ٹولز جو براؤزرز کو خودکار بناتے ہیں، وہ خود پیمائش کے عمل کا حصہ ہوتے ہیں۔
  • ناممکن نظر آنے والے بینچ مارکس کی جانچ ضروری ہے۔ اگر اعداد و شمار نیٹ ورک کی صلاحیت سے بہت زیادہ مختلف ہوں، تو پیمائش کا ماحول پہلا مشکوک ہونا چاہیے۔
  • ایک صفر نتیجہ بھی قیمتی ہے۔ یہ تصدیق کرنا کہ کسی تبدیلی سے کوئی فرق نہیں پڑ رہا، خیالی بگ (phantom bugs) کے پیچھے وقت ضائع کرنے سے بچاتا ہے۔
  • دستی کنٹرول سستا بیمہ ہے۔ ایک سادہ براؤزر ونڈو میں وہی آپریشن چلا کر آپ پوشیدہ انسٹرومینٹیشن اوور ہیڈ (instrumentation overhead) کا پتہ لگا سکتے ہیں۔

دوسرا پہلو: جب ڈیبگر ناگزیر ہوں

ڈیبگر پیج کے طرزِ عمل، ایرر ٹریسز، اور نیٹ ورک ٹائم لائنز کی ایسی بصیرت فراہم کرتے ہیں جو ورنہ حاصل نہیں کی جا سکتی۔ ریگریشن ٹیسٹنگ، سیکیورٹی آڈٹ، یا پیچیدہ UI انٹرایکشنز کے لیے، CDP ڈیبگر منسلک کرنا اکثر ناگزیر ہوتا ہے۔ اہم بات یہ ہے کہ فنکشنل ٹیسٹنگ کو خام پرفارمنس پیمائش سے الگ رکھا جائے، اور جب مقصد پرفارمنس پیمائش ہو تو ڈیبگر کو غیر فعال کر دیا جائے۔

حاصلِ کلام: وہ ٹولز جو خودکار ٹیسٹنگ کو ممکن بناتے ہیں، وہ پرفارمنس میں بگاڑ کا سب سے بڑا ذریعہ بھی بن سکتے ہیں۔ براؤزر، نیٹ ورک، یا کوڈ کو قصوروار ٹھہرانے سے پہلے، اس بات کی تصدیق کر لیں کہ کہیں کوئی ڈیبگر خاموشی سے ڈیٹا اسٹریم کو محدود تو نہیں کر رہا۔