परफ़ॉर्मेंस टेस्टिंग क्या है?

परफ़ॉर्मेंस टेस्ट के प्रकार

• लोड टेस्टिंग — अपेक्षित, रियलिस्टिक ट्रैफ़िक (औसत और पीक) यह पुष्टि करने के लिए कि सिस्टम सामान्य हालात में रिस्पॉन्स-टाइम और एरर लक्ष्य पूरे करता है।
• स्ट्रेस टेस्टिंग — अपेक्षित पीक से आगे ट्रैफ़िक बढ़ाना जब तक कुछ टूट न जाए, ताकि सीमा पता चले और दिखे कि फ़ेलियर शालीन है (धीमा, 503) या विनाशकारी (क्रैश, डेटा करप्शन)।
• स्पाइक टेस्टिंग — कम से बहुत ज़्यादा ट्रैफ़िक की अचानक छलाँग, जैसे मार्केटिंग कैंपेन या फ़्लैश सेल में, ऑटोस्केलिंग और क्यूइंग जाँचने के लिए।
• सोक (एंड्योरेंस) टेस्टिंग — घंटों या दिनों तक मध्यम लोड, मेमोरी लीक, कनेक्शन पूल ख़त्म होने और डिस्क बढ़ने जैसी चीज़ें पकड़ने के लिए जो छोटे टेस्ट कभी नहीं दिखाते।
• स्केलेबिलिटी टेस्टिंग — लोड चरणों में बढ़ाकर यह सीखना कि रिसोर्स जोड़ने पर थ्रूपुट और लेटेंसी कैसे बदलती है।
• बेंचमार्किंग — दो वर्ज़न या दो इम्प्लीमेंटेशन की तुलना के लिए एक एंडपॉइंट का तेज़, दोहराने योग्य माप।

आज़माएँ: HTTP रिक्वेस्ट बेंचमार्क आज़माएँ: API परफ़ॉर्मेंस कंपेरेटर

अहम मेट्रिक्स

• रिस्पॉन्स टाइम — हर रिक्वेस्ट पर मापा जाता है। औसत नहीं, परसेंटाइल रिपोर्ट करें: p50 (मीडियन), p95 और p99 बताते हैं ज़्यादातर यूज़र और सबसे बदक़िस्मत यूज़र क्या अनुभव करते हैं। औसत धीमी पूँछ छिपा देता है।
• थ्रूपुट — प्रति सेकंड रिक्वेस्ट (या ट्रांज़ैक्शन) जो सिस्टम बनाए रखता है।
• एरर रेट — फ़ेल होने वाली रिक्वेस्ट का प्रतिशत (5xx, टाइमआउट, कनेक्शन एरर)। लक्ष्य लोड पर यह शून्य के पास रहना चाहिए।
• कॉन्करेंसी — एक साथ कितने वर्चुअल यूज़र या खुले कनेक्शन सक्रिय हैं।
• रिसोर्स उपयोग — सर्वर साइड पर CPU, मेमोरी, डेटाबेस कनेक्शन, क्यू डेप्थ, लोड टाइमलाइन से जोड़कर।
• Apdex या SLO अनुपालन — तय बजट के अंदर रिक्वेस्ट का हिस्सा (जैसे 95% 300 ms से कम)।

आज़माएँ: रिस्पॉन्स टाइम एनालाइज़र आज़माएँ: रिस्पॉन्स साइज़ एनालाइज़र

पहला परफ़ॉर्मेंस टेस्ट प्लान करना

• लक्ष्य को नंबर के रूप में तय करें: "500 कॉन्करेंट यूज़र के साथ checkout p95 पर 800 ms से कम में पूरा हो और 0.1% से कम एरर हों"।
• हर पेज के बजाय अहम जर्नी चुनें — लॉगिन, सर्च, कार्ट में जोड़ना, checkout, टॉप तीन API एंडपॉइंट।
• रियलिस्टिक ट्रैफ़िक मॉडल करें: जर्नी का मिक्स, एक्शन के बीच थिंक टाइम, रैम्प-अप और स्टेडी स्टेट। प्रोडक्शन एनालिटिक्स हो तो इस्तेमाल करें।
• बड़े पैमाने पर टेस्ट डेटा तैयार करें: हज़ारों अलग यूज़र, प्रोडक्ट और पेलोड ताकि कैश और यूनिक कंस्ट्रेंट प्रोडक्शन की तरह व्यवहार करें।
• ऐसे एनवायरनमेंट में चलाएँ जो साइज़ में प्रोडक्शन जैसा हो, या नतीजों को सोच-समझकर स्केल करें। लैपटॉप-साइज़ डेटाबेस प्रोडक्शन वाले के बारे में कुछ नहीं बताएगा।
• पहले एक यूज़र से बेसलाइन बनाएँ, फिर रैम्प करें। हर बाद के रन की बेसलाइन से तुलना करें।
• रन के दौरान सर्वर साइड मॉनिटर करें; अकेले क्लाइंट-साइड नंबर नहीं बता सकते कि यह धीमा क्यों हुआ।

आज़माएँ: लोड टेस्ट डेटा जनरेटर आज़माएँ: Concurrent रिक्वेस्ट टेस्ट जनरेटर

टूल्स: JMeter, k6, Gatling और ब्राउज़र टूल्स

Apache JMeter GUI, रिकॉर्डर और CSV डेटा सेट वाला पुराना ओपन-सोर्स विकल्प है; k6 स्क्रिप्ट-आधारित (JavaScript), हल्का और CI-फ़्रेंडली है; Gatling Scala/Java-आधारित है, बेहतरीन रिपोर्ट के साथ; Locust Python-आधारित है। क्लाउड सर्विसेज़ (BlazeMeter, Grafana Cloud k6, Azure Load Testing) वही स्क्रिप्ट कई रीजन से चलाती हैं।

ब्राउज़र प्रोडक्शन-स्केल लोड नहीं बना सकता, लेकिन ब्राउज़र टूल्स लोड टेस्ट के आसपास के स्टेप के लिए आदर्श हैं: एक एंडपॉइंट के रिस्पॉन्स टाइम डिस्ट्रीब्यूशन को मापना, दो एंडपॉइंट की तुलना, पेलोड साइज़ और कम्प्रेशन जाँचना, और रनर के लिए CSV और JSON डेटा फ़ाइलें बनाना।

आज़माएँ: JMeter टेस्ट डेटा जनरेटर आज़माएँ: JMeter CSV जनरेटर आज़माएँ: HTTP रिक्वेस्ट बेंचमार्क

नतीजे पढ़ना

• थ्रूपुट के सपाट होते हुए लेटेंसी बढ़ना मतलब बॉटलनेक आ गया — CPU, डेटाबेस, कनेक्शन पूल या डाउनस्ट्रीम API।
• लेटेंसी से पहले एरर रेट का बढ़ना अक्सर सुस्ती नहीं, कोई सीमा (max connections, रेट लिमिट) होती है।
• p99 का p95 से बहुत ऊपर होना गार्बेज कलेक्शन पॉज़, लॉक कंटेंशन या कुछ रिक्वेस्ट पर पड़ने वाली धीमी डिपेंडेंसी की ओर इशारा करता है।
• सोक टेस्ट में धीमी गिरावट लीक है: मेमोरी, फ़ाइल हैंडल या कनेक्शन।
• दूसरे रन में रिप्रोड्यूस न होने वाला नतीजा शोर है; कोड ट्यून करने से पहले एनवायरनमेंट ठीक करें।

आज़माएँ: API परफ़ॉर्मेंस कंपेरेटर आज़माएँ: कैश हेडर एनालाइज़र

आम गलतियाँ

• एक यूज़र id या एक प्रोडक्ट से टेस्ट करना — सब कुछ कैश से आता है और नंबर कल्पना होते हैं।
• तुरंत फ़ुल लोड पर रैम्प करना, फिर ऐसे स्पाइक के लिए सिस्टम को दोष देना जिसके लिए वह बना ही नहीं था।
• औसत रिपोर्ट करना। हमेशा एरर रेट के साथ p95 और p99 रिपोर्ट करें।
• लोड जनरेटर को उसी मशीन पर चलाना जिस पर टेस्ट होने वाला सिस्टम है।
• पेलोड साइज़ नज़रअंदाज़ करना: 2 MB का JSON रिस्पॉन्स धीमा है चाहे सर्वर कितना भी तेज़ हो।
• लॉन्च से पहले एक बार टेस्ट करना और फिर कभी नहीं। परफ़ॉर्मेंस एक-एक कमिट में गिरती है।

आज़माएँ: रिस्पॉन्स साइज़ एनालाइज़र आज़माएँ: लोड टेस्ट डेटा जनरेटर

अक्सर पूछे जाने वाले सवाल