JavaScript टूलिंग क्षेत्रातील बहुतेक परफॉर्मन्सचे दावे दुधासारख्या अल्प मुदतीचे असतात. कोणीतरी एका शांत मंगळवारी सकाळी काही पॅकेजेस इन्स्टॉल करते, टर्मिनल आउटपुट कॅप्चर करते आणि एक नाट्यमय बार चार्ट प्रकाशित करते. पुढच्या स्प्रिंटपर्यंत, त्यापैकी एका टूलने एक पॅच रिलीज केलेला असतो जो संपूर्ण माहिती चुकीची ठरवतो. तरीही, तो पोस्ट सर्च इंजिनमध्ये इंडेक्स केलेला राहतो. तो चार्ट शेअर केला जात राहतो. मात्र, आकडेवारी आधीच तुम्हाला फसवतेय.

हा तो दोष आहे जो जवळजवळ सर्व पॅकेज मॅनेजर बेंचमार्कमध्ये आढळतो. आपल्याला ज्या 'लाईव्ह फीड'ची गरज आहे, त्याऐवजी हे केवळ 'इव्हेंट फोटोग्राफी' (क्षणचित्रे) आहेत.

depjs/canary नावाचा प्रकल्प या समस्येकडे कंटेंट कॅलेंडरचे काम म्हणून न पाहता, मशीनची जबाबदारी म्हणून पाहतो. हा एक जिवंत बेंचमार्क आहे जो npm, pnpm, Yarn आणि dep वर लक्ष ठेवतो आणि त्यांपैकी कोणीही नवीन व्हर्जन प्रकाशित करताच त्याची संपूर्ण सुईट (suite) पुन्हा चालवतो. याचे निकाल सार्वजनिक, निरंतर आणि टाळता न येण्यासारखे आहेत. जेव्हा काही बिघडते, तेव्हा रिपॉझिटरी जोपर्यंत सुधारत नाही तोपर्यंत 'रेड' (लाल) राहते. येथे माहिती निवडणे (cherry-picking), जुन्या ब्लॉग पोस्टमागे लपणे किंवा गेल्या महिन्याचा विजेता अजूनहीครองत आहे असे गृहीत धरणे, याला जागा नाही.

वेगाच्या दाव्यांना 'एक्सपायरी डेट' का आवश्यक आहे

JavaScript पॅकेज मॅनेजर्स स्थिर राहत नाहीत. मायनर व्हर्जनमधील फरकामध्ये रिझोल्यूशन अल्गोरिदमचे पुनर्लेखन, बदललेली होस्टिंग स्ट्रॅटेजीज किंवा ग्लोबल कॅश कशी की (key) केली जाते यातील बदल असू शकतात. npm 10.2.1 आणि pnpm 8.11.0 चे बेंचमार्क तुम्हाला दोन रिलीज नंतर त्याच टूल्सचे वर्तन कसे असेल याबद्दल जवळजवळ काहीच सांगू शकत नाही. तरीही, वेबवर अशाच प्रकारच्या गोठवलेल्या स्नॅपशॉटवर आधारित "टूल X हे तीन पटीने वेगाने चालते" सारखे ठाम विधानं भरभरून आढळतात.

त्याहून वाईट म्हणजे, अनेक चाचण्या डेव्हलपर्सना येणाऱ्या वास्तविक अडचणींकडे दुर्लक्ष करतात. एखादे पॅकेज मॅनेजर वॉर्म (warm) आणि व्यवस्थित तयार असलेल्या वातावरणात इन्स्टॉलेशन वेगाने पूर्ण करू शकते, परंतु रिकाम्या डिस्कसह सुरू होणाऱ्या CI रनरवर ते अत्यंत संथ गतीने चालते. दोन्ही टोकाच्या परिस्थितींची चाचणी घेतल्याशिवाय, बेंचमार्क हा उपयुक्त इंजिनिअरिंग डेटाऐवजी केवळ एक प्रेस रिलीज बनून राहतो.

कॅनरी (Canary) तुलना कशी स्वयंचलित करते

दर दोन तासांनी, एक जॉब npm रजिस्ट्री तपासतो (polls). जर npm, pnpm, Yarn किंवा dep चे नवीन व्हर्जन दिसले, तर कॅनरी सक्रिय होते. चेंजलॉग (changelog) कोणी लक्षात घेण्याची ती वाट पाहत नाही. ते लगेच एक पूर्ण टेस्ट मॅट्रिक्स कार्यान्वित करते, ज्यामध्ये चारही मॅनेजर्सची तुलना पाच लोकप्रिय, वास्तविक जगातील पॅकेजेससोबत केली जाते. यामध्ये React, Next.js आणि Vite सारख्या मोठ्या पॅकेजेसचा समावेश आहे, जे कोडबेस प्रत्यक्ष डेव्हलपर्स दररोज इन्स्टॉल करतात. हे एखाद्या विशिष्ट टूलचे कौतुक करण्यासाठी बनवलेले कृत्रिम मायक्रो-प्रोजेक्ट्स नाहीत.

हा रिलीज-ट्रिगर दृष्टिकोन महत्त्वाचा आहे कारण ते मोजमाप थेट बदलांशी जोडते. जर बेंचमार्क फक्त नाईटली शेड्युलवर चालला असता, तर कदाचित तो दिवसाच्या मध्यात आलेला हॉटफिक्स किंवा तासनतास चालणारे रिग्रेशन (regression) मिस करू शकला असता. नवीन व्हर्जनवर विशेषतः चालल्यामुळे, कॅनरी प्रत्येक वेळी एक थेट प्रश्न विचारते: या रिलीजमुळे गोष्टी सुधारल्या की बिघडल्या?

चार परिस्थिती ज्या वेगवेगळ्या पैलूंवर ताण देतात

टेस्ट मॅट्रिक्स चार वेगवेगळ्या सेटअपभोवती तयार केले आहे जे तुमच्या वर्कफ्लोशी थेट संबंधित आहेत.

  • कोल्ड कॅश (Cold cache), लॉकफाइल नाही. हे नवीन लॅपटॉपवर केलेले फ्रेश क्लोन किंवा node_modules डिलीट केल्यानंतर केलेले पहिले इन्स्टॉलेशन आहे. येथे काहीही कॅश केलेले नाही आणि काहीही पिन केलेले नाही. पॅकेज मॅनेजरला सर्व काही शून्यापासून रिझॉल्व्ह, फेच आणि राईट करावे लागते.
  • वॉर्म कॅश (Warm cache), लॉकफाइलसह. जेव्हा सर्व काही व्यवस्थित चालते, तेव्हा कंटिन्यूअस इंटिग्रेशनसाठी (CI) हा आदर्श मार्ग असतो. लॉकफाइल स्थानिक पातळीवर उपलब्ध असते आणि कॅशमध्ये मागील रनचे टार्बॉल्स (tarballs) साठवलेले असतात. बहुतेक निर्णय आधीच घेतले गेलेले असल्याने टूलने वेगाने काम करणे अपेक्षित आहे.
  • कोल्ड कॅश (Cold cache), लॉकफाइलसह. येथे लॉकफाइल उपलब्ध आहे, परंतु कॅश पुसून टाकली गेली आहे. मॅनेजर डिपेंडन्सी रिझोल्यूशन वगळू शकतो, तरीही त्याला नेटवर्कवरून प्रत्येक बाइट डाउनलोड करावा लागतो. यामुळे नेटवर्क स्पीड आणि रिझोल्यूशन स्पीड एकमेकांपासून वेगळे होतात.
  • वॉर्म कॅश (Warm cache), लॉकफाइल नाही. कॅश उपलब्ध आहे, परंतु लॉकफाइल नाही. फाईल्स एक्सट्रॅक्ट करण्यास सुरुवात करण्यापूर्वी पॅकेज मॅनेजरला डिपेंडन्सी ट्री पुन्हा रिझॉल्व्ह करावा लागतो. हे आदर्श नेटवर्क परिस्थितीत सॉल्वर आणि मेटाडेटा पार्सरची कार्यक्षमता तपासते.

प्रत्येक परिस्थिती पाच वेळा कार्यान्वित केली जाते आणि कॅनरी त्याचा मध्यक निकाल (median result) ठेवते. हा एक निर्णय मोठा गोंधळ (noise) कमी करतो. नेटवर्कमधील एखादी तात्पुरती अडचण किंवा रजिस्ट्री लॅटन्सीमधील अल्प वाढ संपूर्ण निष्कर्ष बदलू शकत नाही. आउटलायर (outlier) दुर्लक्षित केला जातो; सामान्य अनुभव नोंदवला जातो.

स्मोक टेस्ट्स (Smoke Tests) रिकाम्या टाइमर्सपेक्षा सरस आहेत

जर तुम्ही निकालाची पडताळणी केली नाही, तर केवळ वेग दाखवणे सोपे आहे. एखादा पॅकेज मॅनेजर postinstall पायऱ्या वगळू शकतो, काही symlinks खराब करू शकतो किंवा चुकीचे व्हर्जन इन्स्टॉल करू शकतो आणि तरीही एक प्रभावी टाइमस्टॅम्प दाखवू शकतो. canary केवळ टाइमरवर थांबण्यास नकार देते. इन्स्टॉलेशन पूर्ण झाल्यानंतर, ती प्रत्यक्षात इन्स्टॉल केलेल्या कोडची चाचणी करते.

उदाहरणार्थ, ते एक Express ॲप्लिकेशन सुरू करते आणि सर्व्हर अपेक्षित पोर्टवर ऐकण्यास (listening) सुरुवात करतो याची खात्री करते. जर कोड चालला नाही, तर बेंचमार्क पूर्णपणे अयशस्वी ठरतो. ही स्मोक टेस्ट या संचाला (suite) केवळ शर्यतीकडून ऑडिटमध्ये रूपांतरित करते. हे त्या प्रश्नाचे उत्तर देते जो केवळ वेग देऊ शकत नाही: इन्स्टॉलेशन खरोखर काम करते का?

एक वैशिष्ट्य म्हणून कट्टर प्रामाणिकपणा

canary च्या लेखकाने प्रक्रियेमध्ये तीन नियम लिहिले आहेत, ज्यांना बहुतेक बेंचमार्क लेखक ऐच्छिक मानतात.

समान मैदान. विविध टूल्समधील वर्तन सुसंगत करण्यासाठी फ्लॅग्सचा वापर केला जातो. जर एखादा पॅकेज मॅनेजर डिफॉल्ट सेटिंगच्या मागे कामगिरीतील त्रुटी लपवत असेल, तर बेंचमार्क ती त्रुटी उघड करतो, ज्यामुळे ते टूल चुकून चांगले दिसू नये.

खरे कोल्ड स्टार्ट्स. केवळ पहिल्यांदाच नाही, तर प्रत्येक पुनरावृत्तीपूर्वी, npm cache आणि pnpm store पूर्णपणे क्लिअर केले जातात. त्यातील "प्रत्येक" (every) या शब्दाचे महत्त्व खूप मोठे आहे. अनेक बेंचमार्क एकदा कॅशे क्लिअर करतात आणि नंतर सलग पाच वेळा इन्स्टॉलेशन चालवतात. दुसऱ्या ते पाचव्या वेळेस होणारे इन्स्टॉलेशन खरोखर 'कोल्ड' नसतात आणि त्यानुसार आकडेवारी फुगलेली दिसते. canary प्रत्येक वेळी शून्यापासून सुरुवात करते.

सार्वजनिक अपयशाची स्थिती. जेव्हा एखादे नवीन रिलीज काहीतरी बिघडवते, तेव्हा रिपॉझिटरी 'रेड फेल्युअर स्टेट'मध्ये राहते. जोपर्यंत दुरुस्ती (fix) उपलब्ध होत नाही, तोपर्यंत ती समोरच्या पानावर, विस्कळीत आणि न सुटलेल्या स्वरूपात दिसते. डॅशबोर्ड हिरवा दिसण्यासाठी त्रुटी शांतपणे दाबून टाकल्या जात नाहीत. हे धोरण पारदर्शकता सुनिश्चित करते. टूल्सचे मूल्यमापन करणारा वापरकर्ता केवळ कोणते टूल सर्वात वेगवान आहे हेच नाही, तर काळानुसार कोणते टूल विश्वासार्ह राहिले आहे हे देखील पाहू शकतो.

तपासण्यायोग्यता ही तडजोड न करण्यायोग्य गोष्ट आहे

ज्या बेंचमार्कचे तुम्ही पुनरुत्पादन (reproduce) करू शकत नाही, तो केवळ एक प्रचार नारा आहे. canary हे एका सिंगल bash स्क्रिप्टद्वारे सोडवते, ज्यामुळे कोणीही या संचाचा (suite) कोणताही भाग स्थानिक पातळीवर (locally) चालवू शकतो. तुम्हाला क्लाउड प्रोव्हायडरच्या नेटवर्किंगवर किंवा मेंटेनरने स्वतः हाताने बदललेल्या वातावरणावर (environment) विश्वास ठेवण्याची गरज नाही. जर तुम्हाला आकडेवारी चुकीची वाटत असेल, तर तुम्ही स्वतःची आकडेवारी तयार करू शकता.

ही पारदर्शकता प्रकल्पाला मेंटेनरसाठी देखील उपयुक्त बनवते. जेव्हा एखादी रिग्रेशन (regression) समस्या येते, तेव्हा डाउनस्ट्रीम डेव्हलपर स्क्रिप्ट घेऊ शकतो, टूलच्या रिलीजचे बायसेक्ट (bisect) करू शकतो आणि अपस्ट्रीम टीमला a