परफ़ॉर्मेंस टेस्टिंग क्या है?
परफ़ॉर्मेंस टेस्टिंग मापती है कि सिस्टम निर्धारित वर्कलोड में कैसे व्यवहार करता है: रिस्पॉन्स टाइम (आमतौर पर औसत नहीं, 95वाँ पर्सेंटाइल), थ्रूपुट (रिक्वेस्ट प्रति सेकंड) और एरर रेट, साथ में CPU, मेमोरी और डेटाबेस की संतृप्ति पर नज़र। लोड टेस्टिंग अपेक्षित ट्रैफ़िक इस्तेमाल करती है, स्ट्रेस टेस्टिंग उससे आगे जाकर टूटने का बिंदु खोजती है, सोक टेस्टिंग घंटों तक लोड रखकर लीक उजागर करती है, और स्पाइक टेस्टिंग अचानक उछाल से रिकवरी जाँचती है।
गाइड पढ़ें: परफ़ॉर्मेंस टेस्टिंग क्या है?
API परफ़ॉर्मेंस कंपेरेटर कैसे इस्तेमाल करें
- Endpoint A और Endpoint B डालें (जैसे v1 और v2, या दो अलग region) और चाहें तो लेबल भी।
- हर endpoint के लिए रिक्वेस्ट की संख्या (≤ 25), concurrency और method चुनें; ज़रूरत हो तो साझा हेडर जोड़ें।
- "Compare" दबाएँ — relay एक जैसी सेटिंग के साथ पहले A और फिर B को मापता है।
- नतीजा पढ़ें: माध्यिका पर कौन-सा endpoint तेज़ है और क्या यह अंतर सार्थक है।
- अगर नतीजा "शोर के दायरे में" आता है तो ज़्यादा सैंपल के साथ दोहराएँ।
API परफ़ॉर्मेंस कंपेरेटर की खूबियाँ
- दो सार्वजनिक endpoint पर एक ही सीमित सैंपल, एक के बाद एक चलाता है
- माध्यिका, औसत, p90/p95/p99, न्यूनतम/अधिकतम और throughput की आमने-सामने तालिका
- हर मीट्रिक के लिए प्रतिशत अंतर और "बेहतर कौन" वाला कॉलम
- significance संकेत: क्या दोनों माध्यिकाओं में कम से कम 20% का और बड़े मानक विचलन से ज़्यादा का अंतर है?
- दोनों endpoint के लिए एरर दर और स्टेटस का ब्योरा
- p50 और p95 की तुलना करता चार्ट
API परफ़ॉर्मेंस कंपेरेटर का उदाहरण
किसी search endpoint का v1 बनाम v2
इनपुट:
A: https://api.example.com/v1/search?q=shoes
B: https://api.example.com/v2/search?q=shoes
Requests: 10 eachआउटपुट:
Faster (median): v2 (1.6× at p50)
p50 A → B: -38% · p95 A → B: -41%
Significance: likely real
Median: 412 ms vs 256 ms · p95: 640 ms vs 377 msAPI परफ़ॉर्मेंस कंपेरेटर के बारे में अक्सर पूछे जाने वाले सवाल
तुलना निष्पक्ष कैसे रहती है?
दोनों endpoint को एक ही relay से एक जैसा method, हेडर, रिक्वेस्ट संख्या और concurrency मिलता है, और वे एक के बाद एक चलते हैं ताकि bandwidth के लिए आपस में होड़ न करें।
"शोर के दायरे में" का क्या मतलब है?
दोनों माध्यिकाओं का अंतर 20% से कम है, या दोनों रन के मानक विचलनों में से बड़े वाले से छोटा है, इसलिए वह महज़ रैंडम उतार-चढ़ाव हो सकता है। नतीजा निकालने से पहले सैंपल बढ़ाएँ या रन दोहराएँ।
क्या मैं staging की तुलना production से कर सकता हूँ?
हाँ, बशर्ते दोनों URL सार्वजनिक हों और आपको उन पर कुछ रिक्वेस्ट भेजने की अनुमति हो। production के लिए रिक्वेस्ट की संख्या कम रखें।
माध्यिका के साथ p95 की तुलना क्यों करें?
दो endpoint की माध्यिका एक जैसी हो सकती है, फिर भी एक की tail कहीं ज़्यादा मोटी हो सकती है। p95 कॉलम सबसे धीमे यूज़र का अनुभव दिखाता है।
क्या रिस्पॉन्स साइज़ की भी तुलना होती है?
जब relay बॉडी का साइज़ बताता है तो वह एक अतिरिक्त पंक्ति के रूप में दिखता है; वरना हर URL पर रिस्पॉन्स साइज़ एनालाइज़र इस्तेमाल करें।
तकनीकी नोट्स
दोनों रन एक के बाद एक चलाने से वे एक ही relay के bandwidth के लिए आपस में होड़ नहीं करते, वरना लोड में जो endpoint दूसरे नंबर पर चलता उसे नुक़सान होता। इसकी क़ीमत यह है कि दोनों रन के बीच नेटवर्क की स्थिति बदल सकती है; इसीलिए significance संकेत किसी अंतर को "likely real" तभी कहता है जब धीमी माध्यिका तेज़ वाली की कम से कम 1.2 गुना हो और दोनों का अंतर दोनों मानक विचलनों में से बड़े वाले से ज़्यादा हो; बाक़ी हर नतीजे को संभावित शोर के रूप में चिह्नित किया जाता है।
संदर्भ
- Apache JMeter User's ManualJMeter से लोड टेस्ट कैसे बनाएँ, पैरामीटराइज़ करें और चलाएँ, और उसके लिसनर व रिपोर्ट कैसे पढ़ें।
- Release It! Second Edition: Design and Deploy Production-Ready Software (Michael T. Nygard)स्थिरता पैटर्न — टाइमआउट, सर्किट ब्रेकर, बल्कहेड, बैक-प्रेशर — और वे विफलता के तरीके जिन्हें लोड टेस्टिंग खोजने के लिए है।
- Site Reliability Engineering: How Google Runs Production Systemsसर्विस लेवल ऑब्जेक्टिव, एरर बजट, "चार गोल्डन सिग्नल" की निगरानी और ओवरलोड संभालना — लचीलेपन का परिचालन पक्ष।