परफ़ॉर्मेंस टेस्टिंग क्या है?
परफ़ॉर्मेंस टेस्टिंग मापती है कि सिस्टम निर्धारित वर्कलोड में कैसे व्यवहार करता है: रिस्पॉन्स टाइम (आमतौर पर औसत नहीं, 95वाँ पर्सेंटाइल), थ्रूपुट (रिक्वेस्ट प्रति सेकंड) और एरर रेट, साथ में CPU, मेमोरी और डेटाबेस की संतृप्ति पर नज़र। लोड टेस्टिंग अपेक्षित ट्रैफ़िक इस्तेमाल करती है, स्ट्रेस टेस्टिंग उससे आगे जाकर टूटने का बिंदु खोजती है, सोक टेस्टिंग घंटों तक लोड रखकर लीक उजागर करती है, और स्पाइक टेस्टिंग अचानक उछाल से रिकवरी जाँचती है।
गाइड पढ़ें: परफ़ॉर्मेंस टेस्टिंग क्या है?
रिस्पॉन्स टाइम एनालाइज़र कैसे इस्तेमाल करें
- कोई सार्वजनिक http(s) URL डालें (relay प्राइवेट और loopback पतों को मना कर देता है)।
- सैंपल की संख्या (1–20) और method (GET, HEAD या OPTIONS) चुनें।
- "Measure" दबाएँ और आँकड़े पढ़ें: माध्यिका सामान्य latency बताती है, p95/p99 पूँछ (tail) बताते हैं।
- रन की आपस में तुलना करने से पहले consistency स्कोर और चार्ट में आउटलायर देख लें।
- सैंपल CSV के रूप में डाउनलोड करें, या किसी बदलाव से पहले/बाद की तुलना के लिए दोबारा चलाएँ।
रिस्पॉन्स टाइम एनालाइज़र की खूबियाँ
- Mutqan relay से 1–20 क्रमिक रिक्वेस्ट भेजता है और हर सैंपल रिकॉर्ड करता है
- न्यूनतम, अधिकतम, औसत, माध्यिका, p90, p95, p99 और मानक विचलन
- consistency स्कोर जो jitter और cold-start आउटलायर उजागर करता है
- हर सैंपल का बार चार्ट और साथ में latency वितरण की तालिका
- स्टेटस का ब्योरा, ताकि फ़ेल या rate-limit हुई रिक्वेस्ट औसत में कभी छिप न जाएँ
- रिपोर्ट और डैशबोर्ड के लिए कच्चे सैंपल की CSV डाउनलोड
रिस्पॉन्स टाइम एनालाइज़र का उदाहरण
किसी health endpoint पर दस सैंपल
इनपुट:
URL: https://api.example.com/health
Samples: 10आउटपुट:
Samples: 10
Min: 112 ms · Average: 138 ms · Median: 131 ms
p90: 171 ms · p95: 181 ms · p99: 188 ms · Max: 190 ms
Std deviation: 23 ms (17% of average)
Consistency: 82/100 — stable
Statuses: 200 ×10उदाहरण रन: 10 सैंपल, latency ms में
- 112–181 msन्यूनतम से p95 तक
- 181–190 mstail: p95 से ऊपर
- 1112 ms न्यूनतम
- 2131 ms माध्यिका (p50)आधे सैंपल इतने या इससे तेज़ थे: सामान्य latency।
- 3138 ms औसतमाध्यिका से ऊपर, क्योंकि धीमे सैंपल इसे ऊपर खींचते हैं।
- 4171 ms
p90 - 5181 ms
p95इससे धीमे सैंपल tail बनाते हैं; SLO आमतौर पर p95 या p99 लक्ष्यों के रूप में लिखे जाते हैं। - 6188 ms
p99दो सबसे धीमे सैंपल के बीच interpolation से। - 7190 ms अधिकतमसबसे धीमा सैंपल।
10 सैंपल होने पर p99 दो सबसे धीमे सैंपल के बीच interpolation से निकलता है, इसलिए अधिकतम से थोड़ा नीचे आता है: उसे गारंटी नहीं, संकेत मानें।
रिस्पॉन्स टाइम एनालाइज़र के बारे में अक्सर पूछे जाने वाले सवाल
एनालाइज़र कितनी रिक्वेस्ट भेजता है?
Mutqan relay से 1 से 20 तक क्रमिक रिक्वेस्ट, हर रिक्वेस्ट पर timeout और प्रति-IP rate limit के साथ। यह जल्दी health जाँच के लिए बना है, लगातार लोड डालने के लिए नहीं।
p90, p95 और p99 का क्या मतलब है?
ये percentile हैं: p95 = 95% सैंपल कम से कम इतने तेज़ थे। percentile वह tail latency दिखाते हैं जिसे औसत छिपा देता है — इसीलिए SLO आमतौर पर p95 या p99 लक्ष्यों के रूप में लिखे जाते हैं।
मेरे अपने मॉनिटरिंग से यहाँ के आँकड़े ज़्यादा क्यों हैं?
इन समयों में relay से आपके origin तक का नेटवर्क रास्ता भी शामिल होता है। इसलिए निरपेक्ष मिलीसेकंड की जगह सापेक्ष तुलना करें (बदलाव से पहले/बाद, endpoint A बनाम B)।
consistency स्कोर क्या है?
0–100 का स्कोर, जो coefficient of variation (मानक विचलन ÷ औसत) और p95/माध्यिका अनुपात से निकाला जाता है। कम स्कोर jitter दर्शाता है — cold start, caching miss या शोर मचाते upstream कॉल देखें।
क्या मैं प्राइवेट या localhost endpoint टेस्ट कर सकता हूँ?
नहीं। relay प्राइवेट, loopback और link-local पतों को मना कर देता है। इसे सिर्फ़ उन सार्वजनिक URL पर इस्तेमाल करें जिन्हें टेस्ट करने की आपको अनुमति है।
तकनीकी नोट्स
percentile क्रम में लगे सैंपल के बीच linear interpolation से निकाले जाते हैं, जो k6 और अधिकांश APM उत्पादों की परिभाषा से मेल खाता है। सैंपल कम हों तो p99 अधिकतम मान के बहुत क़रीब होता है; उसे गारंटी नहीं, बल्कि एक संकेत मानें।
consistency स्कोर coefficient of variation (मानक विचलन बँटा औसत) और p95/माध्यिका अनुपात को मिलाकर बनता है। पूरी तरह स्थिर endpoint को 100 मिलता है; जिसका p95 माध्यिका से तीन गुना हो, उसे tail वाले हिस्से में 0 मिलता है।
संदर्भ
- 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सर्विस लेवल ऑब्जेक्टिव, एरर बजट, "चार गोल्डन सिग्नल" की निगरानी और ओवरलोड संभालना — लचीलेपन का परिचालन पक्ष।