JavaScript ٹولنگ کی دنیا میں کارکردگی کے زیادہ تر دعوے دودھ کی طرح جلد خراب ہو جانے والے ہوتے ہیں۔ کوئی شخص منگل کی ایک پرسکون صبح چند پیکجز انسٹال کرتا ہے، ٹرمینل کا آؤٹ پٹ لیتا ہے، اور ایک ڈرامائی بار چارٹ شائع کر دیتا ہے۔ اگلے اسپرنٹ تک، ان میں سے ایک ٹول ایک ایسا پیچ (patch) جاری کر چکا ہوتا ہے جو اس پورے دعوے کو غلط ثابت کر دیتا ہے۔ وہ پوسٹ سرچ انجنوں میں انڈیکس رہتی ہے۔ چارٹ شیئر ہوتا رہتا ہے۔ لیکن اعداد و شمار آپ سے جھوٹ بول رہے ہوتے ہیں۔
یہی وہ خرابی ہے جو تقریباً تمام پیکیج مینیجر بینچ مارکس کو متاثر کرتی ہے۔ یہ ایونٹ فوٹوگرافی کی طرح ہے جبکہ ہمیں ایک لائیو فیڈ کی ضرورت ہے۔
depjs/canary نامی ایک پروجیکٹ اس مسئلے کو مواد کے کیلنڈر کے کام کے بجائے ایک مشین کی ذمہ داری کے طور پر لیتا ہے۔ یہ ایک زندہ بینچ مارک ہے جو npm، pnpm، Yarn، اور dep پر نظر رکھتا ہے، اور جیسے ہی ان میں سے کوئی بھی نیا ورژن جاری کرتا ہے، یہ اپنا پورا ٹیسٹ سیٹ دوبارہ چلاتا ہے۔ نتائج عوامی، مسلسل اور ناگزیر ہیں۔ جب کچھ خراب ہوتا ہے، تو ریپوزٹری (repository) ٹھیک ہونے تک 'ریڈ' (red) رہتی ہے۔ یہاں کوئی اپنی مرضی سے ڈیٹا چننے (cherry-picking) کا موقع نہیں، پرانے بلاگ پوسٹ کے پیچھے چھپنے کا کوئی راستہ نہیں، اور یہ فرض کرنے کی گنجائش نہیں کہ پچھلے مہینے کا فاتح اب بھی بادشاہ ہے۔
رفتار کے دعووں کو میعاد ختم ہونے کی ضرورت کیوں ہے
JavaScript پیکیج مینیجرز ایک جگہ ٹھہرے نہیں رہتے۔ مائنر ورژنز کے درمیان فرق میں ریزولوشن الگورتھم کی دوبارہ لکھائی، ہوسٹنگ (hoisting) کی حکمت عملیوں میں تبدیلی، یا گلوبل کیش (global cache) کے کی (key) کے طریقے میں تبدیلی شامل ہو سکتی ہے۔ ایک بینچ مارک جو npm 10.2.1 اور pnpm 8.11.0 کو ریکارڈ کرتا ہے، وہ آپ کو اس بارے میں تقریباً کچھ نہیں بتاتا کہ وہی ٹولز دو ریلیز بعد کیسا برتاؤ کریں گے۔ اس کے باوجود، ویب ایسے حتمی بیانات سے بھری پڑی ہے جیسے "ٹول X تین گنا تیز ہے" جو بالکل اسی طرح کے منجمد اسنیپ شاٹ پر مبنی ہوتے ہیں۔
اس سے بھی بدتر یہ ہے کہ بہت سے ٹیسٹ ان حالات کو نظر انداز کر دیتے ہیں جو اصل ڈویلپر کی مشکلات کو ظاہر کرتے ہیں۔ ایک پیکیج مینیجر ایک گرم اور اچھی طرح سے تیار شدہ ماحول میں انسٹالیشن کو تیزی سے مکمل کر سکتا ہے، لیکن ایک CI رنر پر رینگنے لگتا ہے جو خالی ڈسک کے ساتھ شروع ہوتا ہے۔ دونوں انتہاؤں کا تجربہ کیے بغیر، بینچ مارک کارآمد انجینئرنگ ڈیٹا کے بجائے محض ایک پریس ریلیز بن کر رہ جاتا ہے۔
کینری (Canary) موازنہ کو خودکار کیسے بناتا ہے
ہر دو گھنٹے بعد، ایک جاب npm رجسٹری کو پول (poll) کرتی ہے۔ اگر npm، pnpm، Yarn، یا dep کا نیا ورژن نظر آئے، تو کینری بیدار ہو جاتا ہے۔ یہ چینج لاگ (changelog) پر نظر رکھنے کے لیے کسی انسان کا انتظار نہیں کرتا۔ یہ فوری طور پر ایک مکمل ٹیسٹ میٹرکس چلاتا ہے جو چاروں مینیجرز کا مقابلہ پانچ مقبول اور حقیقی دنیا کے پیکجز سے کرتا ہے۔ اس کے انتخاب میں React، Next.js، اور Vite جیسے بڑے نام شامل ہیں، یہ وہ کوڈ بیسز ہیں جنہیں اصل ڈویلپرز روزانہ انسٹال کرتے ہیں۔ یہ کسی خاص ٹول کی تعریف کرنے کے لیے بنائے گئے مصنوعی مائیکرو پروجیکٹس نہیں ہیں۔
ریلیز سے شروع ہونے والا یہ طریقہ اس لیے اہم ہے کیونکہ یہ پیمائش کو براہ راست تبدیلی سے جوڑ دیتا ہے۔ اگر بینچ مارک صرف رات کے شیڈول پر چلتا، تو شاید یہ دن کے دوران آنے والے کسی ہاٹ فکس (hotfix) کو مس کر دیتا یا گھنٹوں تک کسی ریگریشن (regression) کو نظر انداز کر دیتا۔ نئے ورژنز پر خاص طور پر چلنے کے ذریعے، کینری ہر بار ایک براہ راست سوال پوچھتا ہے: کیا اس ریلیز نے چیزوں کو بہتر بنایا یا بدتر؟
چار منظرنامے جو مختلف پہلوؤں کا امتحان لیتے ہیں
ٹیسٹ میٹرکس چار مختلف سیٹ اپس کے گرد بنایا گیا ہے جو براہ راست ان ورک فلو (workflows) سے مطابقت رکھتے ہیں جنہیں آپ پہچان لیں گے۔
- کولڈ کیش (Cold cache)، کوئی لاک فائل نہیں۔ یہ ایک نئے لیپ ٹاپ پر تازہ کلون (clone) ہے، یا
node_modulesکو حذف کرنے کے بعد پہلی انسٹالیشن ہے۔ کچھ بھی کیش نہیں ہے۔ کچھ بھی پن (pinned) نہیں ہے۔ پیکیج مینیجر کو ہر چیز شروع سے حل (resolve)، فیچ (fetch) اور لکھنی پڑتی ہے۔ - وارم کیش (Warm cache)، لاک فائل کے ساتھ۔ یہ کنٹینیوس انٹیگریشن (CI) کے لیے خوشگوار راستہ ہے جب سب کچھ ٹھیک چل رہا ہو۔ لاک فائل مقامی طور پر موجود ہے، اور کیش میں پچھلے رن کے ٹار بالز (tarballs) موجود ہیں۔ ٹول کو تیزی سے کام کرنا چاہیے کیونکہ زیادہ تر فیصلے پہلے ہی کیے جا چکے ہیں۔
- کولڈ کیش (Cold cache)، لاک فائل کے ساتھ۔ یہاں لاک فائل موجود ہے، لیکن کیش صاف کر دیا گیا ہے۔ مینیجر ڈیپینڈینسی ریزولوشن کو چھوڑ سکتا ہے، لیکن اسے پھر بھی نیٹ ورک کے ذریعے ہر بائٹ ڈاؤن لوڈ کرنا پڑتا ہے۔ یہ نیٹ ورک کی رفتار کو ریزولوشن کی رفتار سے الگ کر دیتا ہے۔
- وارم کیش (Warm cache)، کوئی لاک فائل نہیں۔ کیش گرم ہے، لیکن لاک فائل غائب ہے۔ فائلیں نکالنا شروع کرنے سے پہلے پیکیج مینیجر کو ڈیپینڈینسی ٹری کو دوبارہ حل کرنا ہوگا۔ یہ مثالی نیٹ ورک کی صورتحال میں سالور (solver) اور میٹا ڈیٹا پارسر کی کارکردگی کا امتحان لیتا ہے۔
ہر منظرنامے کو پانچ بار چلایا جاتا ہے، اور کینری میڈین (median) نتیجہ رکھتا ہے۔ یہ ایک انتخاب بہت زیادہ شور (noise) کو ختم کر دیتا ہے۔ نیٹ ورک کی کوئی عارضی خرابی یا رجسٹری لیٹنسی (latency) میں مختصر اضافہ کہانی کو تبدیل نہیں کر سکتا۔ غیر معمولی نتائج (outliers) کو نظر انداز کر دیا جاتا ہے؛ عام تجربے کو ریکارڈ کیا جاتا ہے۔
سموک ٹیسٹ (Smoke Tests) خالی ٹائمرز سے بہتر ہیں
اگر آپ نتیجے کی تصدیق نہیں کرتے تو محض رفتار کو دکھاوا بنانا آسان ہے۔ ایک پیکیج مینیجر پوسٹ انسٹال (postinstall) اقدامات کو چھوڑ سکتا ہے، چند سم لنکس (symlinks) کو خراب کر سکتا ہے، یا غلط ورژن انسٹال کر سکتا ہے اور پھر بھی ایک متاثر کن ٹائم اسٹیمپ دکھا سکتا ہے۔ کینری صرف ٹائمر پر رکنے سے انکار کر دیتی ہے۔ انسٹالیشن مکمل ہونے کے بعد، یہ اصل میں انسٹال شدہ کوڈ کا عملی تجربہ کرتی ہے۔
مثال کے طور پر، یہ ایک Express ایپلی کیشن کو شروع کرتی ہے اور اس بات کی تصدیق کرتی ہے کہ سرور مطلوبہ پورٹ پر سننے (listening) کے لیے تیار ہے۔ اگر کوڈ نہیں چلتا، تو بینچ مارک مکمل طور پر ناکام ہو جاتا ہے۔ سموک ٹیسٹ اس سوٹ کو ایک ریس سے بدل کر ایک آڈٹ بنا دیتا ہے۔ یہ اس سوال کا جواب دیتا ہے جو محض رفتار نہیں دے سکتی: کیا انسٹالیشن واقعی کام کرتی ہے؟
ایک فیچر کے طور پر انتہا درجے کی ایمانداری
کینری کے مصنف نے اس عمل میں تین ایسے اصول لکھے ہیں جنہیں زیادہ تر بینچ مارک مصنفین اختیاری سمجھتے ہیں۔
برابر کا میدان۔ مختلف ٹولز کے درمیان رویے کو ہموار کرنے کے لیے فلیگز (Flags) کا استعمال کیا جاتا ہے۔ اگر کوئی پیکیج مینیجر کسی ڈیفالٹ سیٹنگ کے پیچھے کارکردگی کے نقص کو چھپاتا ہے، تو بینچ مارک اسے اتفاقیہ طور پر اچھا دکھانے کے بجائے بے نقاب کر دیتا ہے۔
حقیقی کولڈ اسٹارٹس (Cold starts)۔ ہر ایک تکرار سے پہلے، نہ کہ صرف پہلی بار، npm کیشے (cache) اور pnpm اسٹور کو صاف کر دیا جاتا ہے۔ لفظ "ہر" (every) یہاں بہت اہم کردار ادا کر رہا ہے۔ بہت سے بینچ مارکس صرف ایک بار کیشے صاف کرتے ہیں، اور پھر لگاتار پانچ انسٹالیشنز چلاتے ہیں۔ دوسری سے پانچویں بار کی انسٹالیشنز حقیقی طور پر "کولڈ" نہیں ہوتیں، اور اس کے نتیجے میں اعداد و شمار بڑھا چڑھا کر دکھائے جاتے ہیں۔ کینری ہر بار صفر سے شروع ہوتی ہے۔
عوامی ناکامی کی حالتیں۔ جب کوئی نیا ورژن کسی چیز کو خراب کرتا ہے، تو ریپوزٹری (repository) سرخ ناکامی کی حالت میں رہتی ہے۔ یہ سامنے والے صفحے پر بدصورت اور غیر حل شدہ حالت میں تب تک موجود رہتی ہے جب تک کہ اس کا حل (fix) فراہم نہ کر دیا جائے۔ ڈیش بورڈ کو سبز دکھانے کے لیے کسی خاموش دباؤ یا چھپانے کا عمل نہیں ہوتا۔ یہ پالیسی شفافیت کو یقینی بناتی ہے۔ ٹولز کا جائزہ لینے والا صارف نہ صرف یہ دیکھ سکتا ہے کہ کون سا سب سے تیز ہے، بلکہ یہ بھی کہ وقت کے ساتھ کون سا زیادہ قابل اعتماد رہا۔
معائنے کی صلاحیت پر کوئی سمجھوتہ نہیں
ایک ایسا بینچ مارک جسے آپ دوبارہ دہرانے (reproduce) کے قابل نہ ہوں، وہ محض ایک انتخابی نعرہ ہے۔ کینری اس مسئلے کو ایک سنگل bash اسکرپٹ کے ذریعے حل کرتی ہے جو کسی کو بھی اس سوٹ کے کسی بھی حصے کو مقامی طور پر (locally) چلانے کی اجازت دیتا ہے۔ آپ کو کسی کلاؤڈ فراہم کنندہ کے نیٹ ورکنگ یا کسی مینٹینر کے ہاتھ سے ترتیب دیے گئے ماحول پر بھروسہ کرنے کی ضرورت نہیں ہے۔ اگر آپ کو شک ہو کہ اعداد و شمار درست نہیں ہیں، تو آپ اپنے اعداد و شمار خود تیار کر سکتے ہیں۔
وہ شفافیت اس پروجیکٹ کو مینٹینرز کے لیے بھی مفید بناتی ہے۔ جب کوئی ریگریشن (regression) سامنے آتی ہے، تو ایک ڈاؤن اسٹریم (downstream) ڈویلپر اسکرپٹ حاصل کر سکتا ہے، ٹول کے ریلیزز کا بائی سیکٹ (bisect) کر سکتا ہے، اور اپ اسٹریم (upstream) ٹیم کو ایک