API परफ़ॉर्मेंस टेस्टिंग टूल्स को तीनों सवालों से मिलाना
क्षमता → लोड जनरेटर
थ्रेड ग्रुप्स, रैंप-अप, डिस्ट्रिब्यूटेड वर्कर्स।
रिलीज़ से पहले और आर्किटेक्चर में बदलाव के बाद चलाएँ। लगातार चलाना महँगा पड़ता है।
रिग्रेशन → टाइमिंग की तुलना
इसके लिए एक बेसलाइन और एक diff चाहिए, हाई concurrency नहीं।
तीनों में सबसे सस्ता और सबसे ज़्यादा बार गायब रहने वाला।
शुद्धता → फंक्शनल वेरिफ़िकेशन
बॉडी पर assertions, अटपटे इनपुट की स्थिति में भी।
बाकी दोनों की बुनियाद।
वह कैटेगरी जो ज़्यादातर टीमों के पास नहीं है
जो भी टीम कहती है कि वह परफ़ॉर्मेंस टेस्टिंग करती है, उसके पास लगभग हमेशा एक लोड जनरेटर होता है। बहुत कम टीमों के पास ऐसा कुछ होता है जो हर बदलाव पर रिग्रेशन की निगरानी करे। लागत और नतीजे, दोनों लिहाज़ से यह उल्टा है।
क्षमता दो रिलीज़ के बीच शायद ही बदलती है, इसलिए उसे लगातार टेस्ट करने से ज़्यादा कुछ पता नहीं चलता। परफ़ॉर्मेंस रिग्रेशन एक-एक pull request करके आता है, और जब तक तिमाही में होने वाला कैपेसिटी रन उसे पकड़ता है, तब तक आपके सामने छह महीने के commits होते हैं और यह अंदाज़ा नहीं होता कि unindexed query किसने जोड़ी।
हर कैटेगरी में क्या देखना चाहिए
लोड जनरेटर: क्या आप रिस्पॉन्स बॉडी पर assert कर सकते हैं, कम से कम कुछ सैंपल पर। ज़्यादातर कर सकते हैं और कम ही टीमें इसे चालू करती हैं, और इसी तरह लोड टेस्ट साफ़ रिपोर्ट देता रहता है जबकि हर रिस्पॉन्स खाली होता है।
रिग्रेशन टूलिंग: क्या यह किसी निरपेक्ष थ्रेशोल्ड के बजाय आपके अपने इतिहास से तुलना करती है। उधार लिए गए लक्ष्य आपके प्रोडक्ट के बारे में कुछ नहीं बताते।
फंक्शनल वेरिफ़िकेशन: क्या इसमें बाउंड्री केस शामिल हैं। बड़े page size पर धीमी पड़ जाने वाली query एक ढाँचागत समस्या है, जो आपको यहाँ उससे बहुत पहले मिल जाएगी जब कोई कैपेसिटी टेस्ट उसे सामने लाएगा।
पर्सेंटाइल को ईमानदारी से पढ़ना
परफ़ॉर्मेंस टूलिंग पर्सेंटाइल रिपोर्ट करती है, और इन्हें अक्सर इस तरह गलत पढ़ा जाता है कि जिस समस्या को आप ढूँढ रहे हैं वही छिप जाती है।
ठीक दिखने वाला p50 आपको बीच वाली request के बारे में बताता है और उन लोगों के अनुभव के बारे में कुछ नहीं कहता जिनकी किस्मत खराब रही। जिस endpoint पर घंटे में हज़ार कॉल आते हैं, वहाँ ठीक दिखने वाले p99 का मतलब भी हर घंटे दस धीमी requests है, यानी दस चिढ़े हुए यूज़र। और सभी endpoints का औसत लगभग बेमतलब है, क्योंकि उसमें health check और रिपोर्ट जनरेशन आपस में मिल जाते हैं।
दो आदतें इसका ज़्यादातर हिस्सा ठीक कर देती हैं। पर्सेंटाइल को कुल मिलाकर देखने के बजाय हर endpoint के हिसाब से देखें, और औसत के बजाय p95 और p99 देखें। जो endpoints मायने रखते हैं उनकी सूची आम तौर पर छोटी होती है, और समय के साथ उन चार संख्याओं पर नज़र रखना एक साथ सब कुछ दिखाने वाले किसी भी डैशबोर्ड से ज़्यादा काम का है।
वह क्रम जो पैसे बचाता है
पहले शुद्धता, फिर रिग्रेशन, फिर क्षमता। जो endpoint गलत चीज़ लौटा रहा हो उस पर लोड टेस्ट करने से एक भरोसेमंद दिखने वाला आँकड़ा मिलता है जो किसी बारे में कुछ नहीं कहता, और परफ़ॉर्मेंस प्रोग्राम अपनी पहली तिमाही सबसे ज़्यादा इसी तरह बर्बाद करते हैं।
टर्मिनल
npm install -g @testsprite/testsprite-cli
testsprite setup
अगर आप लोकल मशीन पर कुछ भी इंस्टॉल नहीं करना चाहते, तो यही सेटअप TestSprite डैशबोर्ड में भी मौजूद है। CLI का बाकी हिस्सा यहाँ देखें: CLI रिपॉज़िटरी।
सेशन, कैप्चर की गई वैल्यू, क्रम और cleanup — इन सबके बारे में यहाँ बताया गया है: API टेस्टिंग डॉक्युमेंटेशन।
दो रास्ते हैं, और चुनाव असल में इस बात का है कि pipeline किसके ज़िम्मे है। डैशबोर्ड से GitHub App जोड़ने पर आपकी रिपॉज़िटरी में कोई बदलाव करने की ज़रूरत ही नहीं पड़ती, क्योंकि यह उसी deployment पर प्रतिक्रिया देता है जो आपका build पहले से भेजता है। वहीं GitHub Actions का एक step जोड़ने पर यह जाँच repo के भीतर आ जाती है, जहाँ बाकी build की तरह इसका भी रिव्यू होता है।
TestSprite क्या जोड़ता है
शुद्धता वाला कॉलम, जो बाकी दोनों की बुनियाद है। यह स्टेटस कोड के बजाय बॉडी पर assert करता है, उन बाउंड्री केस को कवर करता है जो ढाँचागत सुस्ती सामने लाते हैं, और हर pull request पर चलता है।
कवरेज एक discovery पास और आपकी स्पेसिफ़िकेशन से तैयार होता है। Auto-Authentication पूरे रन के दौरान सेशन जीवित रखता है, Dynamic Variables एक कॉल से दूसरी कॉल तक वैल्यू ले जाते हैं, Dependency Chains एग्ज़ीक्यूशन का क्रम निकालते हैं, और Auto-Cleanup ठीक वही हटाता है जो उस रन ने बनाया था।
फ़ायदा यह है कि आपके क्षमता के आँकड़े ऐसी सर्विस का ब्यौरा देने लगते हैं जो सचमुच काम करती है। बड़े page size पर धीमी पड़ने वाली query यहाँ उस लागत के एक छोटे से हिस्से में पकड़ में आ जाती है जो उसे लोड रन में ढूँढने पर लगती, और चुपचाप खाली रिज़ल्ट लौटाने वाला endpoint throughput पर अच्छा स्कोर करना बंद कर देता है।
क्या TestSprite इस कैटेगरी में आता है?
शुद्धता वाले कॉलम में। यह बाउंड्री केस समेत व्यवहार की जाँच करता है, और लगातार लोड पैदा नहीं करता।
क्या एक ही टूल तीनों को कवर कर सकता है?
कुछ टूल ऐसा दावा करते हैं। व्यवहार में लोड पैदा करना और बॉडी पर गहराई से assert करना एक-दूसरे को खींचते हैं, क्योंकि assertions जनरेटर के throughput की कीमत पर आते हैं।
रिग्रेशन के लिए वाजिब थ्रेशोल्ड क्या है?
इसे अपने ही variance से तय करें। अगर शांत माहौल में आपके आँकड़े एक रन से दूसरे रन तक दस प्रतिशत ऊपर-नीचे होते हैं, तो पाँच प्रतिशत का थ्रेशोल्ड सिर्फ़ शोर है।
क्या हमें डिस्ट्रिब्यूटेड लोड जनरेशन चाहिए?
सिर्फ़ तब, जब एक अकेला जनरेटर ही अड़चन बन जाए। कई टीमें ऐसी डिस्ट्रिब्यूटेड क्षमता खरीद लेती हैं जिसे वे कभी पूरी तरह इस्तेमाल ही नहीं करतीं।
इनमें से हर एक कहाँ चलना चाहिए?
शुद्धता और रिग्रेशन हर pull request पर। क्षमता रिलीज़ से पहले और आर्किटेक्चर में बदलाव के बाद।
तीन सवाल, तीन उपकरण।
API परफ़ॉर्मेंस टेस्टिंग टूल्स तीन हिस्सों में बँटते हैं: लोड जनरेटर, रिग्रेशन तुलना और फंक्शनल वेरिफ़िकेशन। ज़्यादातर टीमों के पास पहला है और दूसरा नहीं, और शुद्धता इन दोनों की बुनियाद है।