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

टेस्ट के प्रकार। Product owner, "तेज़" और "पहले दिन क्रैश नहीं": अपेक्षित पीक पर लोड टेस्टिंग, यानी पीक जर्नी मिक्स के साथ 100 रिक्वेस्ट प्रति सेकंड, ताकि रिस्पॉन्स-टाइम और एरर लक्ष्यों की पुष्टि हो; फिर स्ट्रेस टेस्टिंग, जो पीक से आगे लोड बढ़ाती रहती है ताकि सीमा पता चले और दिखे कि सिस्टम शालीनता से फ़ेल होता है (धीमे जवाब, 503 जैसा तुरंत "बाद में कोशिश करें" वाला जवाब) या विनाशकारी तरीके से (क्रैश, खोए हुए या दोहरे registration)। Registrar, "पहले घंटे इस्तेमाल लायक नहीं": स्पाइक टेस्टिंग, यानी 08:00 की तरह एक मिनट के अंदर लगभग शून्य ट्रैफ़िक से पीक और उससे आगे की छलाँग, ताकि क्यूइंग और रिकवरी दिखे। 08:00 पर छात्र सोचने के बजाय refresh करते हैं, इसलिए उतने ही छात्र ज़्यादा रिक्वेस्ट भेजते हैं: स्पाइक को छोटे थिंक टाइम या ज़्यादा रिक्वेस्ट रेट से मॉडल करें। Operations lead, "धीमा होता चला गया": सोक (एंड्योरेंस) टेस्टिंग, सामान्य दिन के लोड पर कई घंटे, हो सके तो कई दिन, और लीक के लिए मेमोरी, कनेक्शन और डिस्क पर नज़र। Architect: स्केलेबिलिटी टेस्टिंग, यानी वही लोड स्टेप पहले एक और फिर दो application servers के साथ; सिर्फ़ यही तुलना दिखाती है कि दूसरे server से थ्रूपुट बढ़ता है या नहीं। Developer: बेंचमार्किंग, यानी पुराने और नए build पर, एक ही डेटा और एनवायरनमेंट के साथ, seat-availability एंडपॉइंट का तेज़, दोहराने योग्य माप, p50 और p95 की तुलना के साथ। समझदारी भरा क्रम: पहले एक यूज़र वाली बेसलाइन और बेंचमार्क, फिर लोड टेस्ट, फिर स्ट्रेस और स्पाइक, फिर स्केलेबिलिटी की तुलना और सोक, और हर fix के बाद लोड टेस्ट दोबारा।

मापने योग्य लक्ष्य। ये प्रस्ताव हैं जिन पर product owner से सहमति लेनी है; सहमति के बाद ये परफ़ॉर्मेंस टेस्ट के exit criteria बनते हैं। पीक: पीक मिक्स (courses सर्च करना 60%, section देखना 25%, section में registration 10%, लॉगिन 5%) के साथ 100 रिक्वेस्ट प्रति सेकंड, 10 मिनट के रैम्प-अप के बाद 30 मिनट तक, प्रोडक्शन-साइज़ staging पर: हर जर्नी के लिए p95 800 ms से कम और p99 2 s से कम, 0.1% से कम रिक्वेस्ट फ़ेल हों, और कोई registration न खोए, न दोहराया जाए। हेडरूम: यही लक्ष्य 150 रिक्वेस्ट प्रति सेकंड पर भी पूरे हों (50% क्यों, यह स्टेप 3 बताता है)। खुलने का स्पाइक: एक मिनट के अंदर लगभग शून्य से 150 रिक्वेस्ट प्रति सेकंड, 15 मिनट तक; कुछ भी क्रैश न हो, कोई registration न खोए, न दोहराया जाए; जिन रिक्वेस्ट को सिस्टम संभाल न सके उन्हें अटकने के बजाय तुरंत साफ़ जवाब मिले; और लोड 100 रिक्वेस्ट प्रति सेकंड पर लौटने के 5 मिनट के अंदर p95 फिर 800 ms से नीचे आ जाए। तीन हफ़्ते: 15 रिक्वेस्ट प्रति सेकंड पर कम से कम 48 घंटे, अंत में p95 पहले घंटे के p95 से 10% से ज़्यादा ऊपर न हो, मेमोरी और डेटाबेस कनेक्शन सपाट रहें, और किसी restart की ज़रूरत न पड़े। पुराना सिस्टम कई दिनों में धीमा होता था, इसलिए इससे छोटा सोक टेस्ट तब तक बहुत कम साबित करता है जब तक आप ये ट्रेंड न देखें। आपके नंबर अलग हो सकते हैं, लेकिन हर लक्ष्य में जर्नी, लोड, परसेंटाइल, एरर रेट, अवधि और एनवायरनमेंट होना चाहिए; "तेज़" और "क्रैश नहीं" इनमें से कुछ भी नहीं बताते।

वर्चुअल यूज़र। हर वर्चुअल यूज़र रिस्पॉन्स का इंतज़ार करता है और फिर अगली रिक्वेस्ट से पहले "सोचता" है, इसलिए Little’s law के अनुसार वर्चुअल यूज़र ≈ रिक्वेस्ट प्रति सेकंड × (औसत रिस्पॉन्स टाइम + औसत थिंक टाइम) = 100 × (0.5 + 7.5) = 800। सिर्फ़ रिस्पॉन्स टाइम से गुणा करना (100 × 0.5 = 50) केवल उस पल चल रही रिक्वेस्ट गिनता है और बहुत कम लोड बनाएगा। 20–50% हेडरूम के साथ यह 960 से 1,200 वर्चुअल यूज़र है, यानी लगभग 120 से 150 रिक्वेस्ट प्रति सेकंड। यहाँ ऊपरी सिरा चुनें: 100 रिक्वेस्ट प्रति सेकंड वह है जो ओवरलोड पुराने सिस्टम ने संभाला, असली माँग नहीं। जो रिक्वेस्ट उस तक पहुँचने से पहले ही ठुकरा दी गईं वे उसके logs में नहीं हैं, और जो छात्र हार मानकर चले गए वे बाद में लौटे। इस आँकड़े को निचली सीमा मानें, और पूछें कि क्या web server ने 08:00 पर ठुकराई गई या टाइमआउट हुई रिक्वेस्ट दर्ज कीं। अगर आप परफ़ॉर्मेंस टेस्ट डेटा जनरेटर में 800 यूज़र और 7,500 ms का स्थिर (constant) थिंक टाइम डालें, तो वह लगभग 104 रिक्वेस्ट प्रति सेकंड का अनुमान देगा, यानी 100 से थोड़ा ज़्यादा, क्योंकि वह हर रिस्पॉन्स के लिए 0.5 s की जगह लगभग 200 ms मानता है।

ड्राफ़्ट प्लान। (1) टेस्ट होने वाले server पर चलता लोड जनरेटर उसी से CPU, मेमोरी और network के लिए होड़ करता है, इसलिए सिस्टम असल से धीमा दिखता है और जनरेटर ख़ुद सीमा बन सकता है: k6 को अलग मशीनों पर चलाएँ और उनका CPU भी देखें। (2) सभी यूज़र के लिए एक account का मतलब है कि उसी छात्र का डेटा कैश से आता है और हर registration उसी छात्र के record पर पड़ता है, इसलिए रीड प्रोडक्शन से तेज़ दिखते हैं और registrations ऐसे टकराते हैं जैसा कोई असली दिन नहीं करता (एक छात्र एक section में दो बार registration नहीं कर सकता): हज़ारों अलग test छात्र बनाएँ, हो सके तो उतने जितने registration करेंगे, CSV डेटा सेट के रूप में, और registrations को कई sections में बाँटें। (3) एक ही सेकंड में 1,200 यूज़र स्पाइक है, लोड टेस्ट नहीं, और उसका फ़ेल होना पीक के बारे में कुछ नहीं बताता: लगभग 10 मिनट में रैम्प-अप करें, 30 मिनट स्टेडी स्टेट रखें, फिर रैम्प-डाउन करें, और लोड टेस्ट पास होने के बाद स्पाइक को उसके अपने लक्ष्य के साथ अलग से टेस्ट करें। (4) औसत धीमी पूँछ छिपाता है, "1 s से कम" पर कभी सहमति नहीं हुई, और एरर जाँचे ही नहीं जाते: हर जर्नी के लिए p50, p95 और p99, थ्रूपुट और एरर रेट के साथ, तय लक्ष्यों के सामने रिपोर्ट करें। (5) 300 छात्र और 40 sections मेमोरी में समा जाते हैं और हर query को तेज़ बना देते हैं, उस नई seat-availability query को भी जिसके बारे में developer ने पूछा: प्रोडक्शन-साइज़ डेटा इस्तेमाल करें, उतने ही छात्र, courses और sections जितने प्रोडक्शन में हैं, generate किए हुए या प्रोडक्शन से कॉपी करके छात्रों की पहचान हटाए हुए। प्लान में छूटा हुआ: लोड से पहले एक यूज़र की बेसलाइन, फिर स्टेप में लोड; जर्नी मिक्स और 7.5 s थिंक टाइम; रन के दौरान सर्वर साइड मॉनिटरिंग (application server का CPU और मेमोरी, डेटाबेस CPU, कनेक्शन पूल, slow queries); यह पक्का करने के लिए दूसरा रन कि नतीजा रिप्रोड्यूस होता है; और product owner के साथ तय लक्ष्य।

नतीजे पढ़ना। पहले workload जाँचें: 800 वर्चुअल यूज़र ने 102 रिक्वेस्ट प्रति सेकंड बनाईं, जैसा फ़ॉर्मूले ने अनुमान लगाया था। पीक पर (स्टेप 3) सभी रिक्वेस्ट को साथ गिनें तो रिस्पॉन्स-टाइम और एरर लक्ष्य पूरे हैं: p95 480 ms, p99 950 ms, एरर 0.04%। लेकिन तालिका हर जर्नी अलग से नहीं दिखाती, और 10% हिस्से वाले registration का p95 बहुत धीमा हो सकता है जबकि कुल p95 नीचे रहे; साथ ही यह स्टेप 10 मिनट चला, लक्ष्य के 30 मिनट नहीं। इसलिए पीक का लक्ष्य पूरा कहने से पहले हर जर्नी का p95 माँगें और 30 मिनट का पूरा लोड टेस्ट चलाएँ। हेडरूम का लक्ष्य फ़ेल है। स्टेप 3 से स्टेप 4 तक 200 और यूज़र ने सिर्फ़ 3 रिक्वेस्ट प्रति सेकंड जोड़ीं (102 से 105), जबकि फ़ॉर्मूला लगभग 125 की उम्मीद करता है, और इसी बीच p50 220 से 1,500 ms पर, p95 4,100 ms पर और एरर 1.2% पर पहुँच गए। थ्रूपुट के सपाट होते हुए लेटेंसी बढ़ना मतलब बॉटलनेक: यह build लगभग 105 रिक्वेस्ट प्रति सेकंड पर रुक जाता है, जो पिछले semester के दर्ज पीक से सिर्फ़ 5% ऊपर है और हेडरूम लक्ष्य के 150 से बहुत नीचे।

संभावित बॉटलनेक डेटाबेस की तरफ़ है, application server के CPU में नहीं। CPU लगभग 75% पर रहता है और थ्रूपुट के साथ चलता है, जबकि डेटाबेस कनेक्शन स्टेप 3 में 50 में से 47 के पीक पर हैं और स्टेप 4 से सभी 50 इस्तेमाल में हैं। जब हर कनेक्शन व्यस्त होता है, नई रिक्वेस्ट एक खाली कनेक्शन का इंतज़ार करती हैं, इसीलिए p50 तक उछलता है, और जो बहुत देर इंतज़ार करती हैं वे फ़ेल होती हैं; स्टेप 3 का p99, जो उसके p95 का लगभग दोगुना है, इस बात से मेल खाता है कि पहली रिक्वेस्ट खाली कनेक्शन का इंतज़ार करने लगी हैं। क्लाइंट-साइड नंबर यह नहीं बता सकते कि पूल छोटा है या queries हर कनेक्शन को बहुत देर पकड़े रहती हैं, जैसे प्रोडक्शन-साइज़ डेटा पर नई seat-availability query; इसलिए developers को डेटाबेस का CPU, slow-query log, lock waits और कनेक्शन के लिए रिक्वेस्ट के इंतज़ार का समय चाहिए। अगर डेटाबेस ख़ुद संतृप्त है तो पूल बड़ा करना fix नहीं है: तब ज़्यादा कनेक्शन उसे और धीमा करते हैं। यह पैटर्न स्टेप 5 में दोहराया जाता है और सर्वर मेट्रिक्स इससे मेल खाते हैं, इसलिए इसके शोर होने की संभावना कम है; फिर भी कोई कोड ट्यून करे, उससे पहले स्टेप 4 दोबारा चलाकर पक्का करें कि यह रिप्रोड्यूस होता है। Architect का सवाल अभी खुला है: दूसरा application server CPU जोड़ता है, जो सीमा नहीं है, और ज़्यादा डेटाबेस कनेक्शन, जो तभी मदद करते हैं जब डेटाबेस के पास क्षमता बची हो; डेटाबेस की सीमा समझ आने के बाद स्केलेबिलिटी टेस्ट इसका जवाब देगा।

आज आप क्या रिपोर्ट करेंगे, तय लक्ष्यों के सामने एक defect के रूप में, product owner और developers को: "Release candidate 3.2.0-rc1, प्रोडक्शन-साइज़ staging, पीक मिक्स, 7.5 s थिंक टाइम, हर स्टेप 10 मिनट। 100 रिक्वेस्ट प्रति सेकंड पर कुल p95 480 ms और एरर 0.04% (हर जर्नी के आँकड़े माँगे गए हैं)। थ्रूपुट लगभग 105 रिक्वेस्ट प्रति सेकंड पर रुक जाता है: 1,000 वर्चुअल यूज़र पर p95 4.1 s और 1.2% रिक्वेस्ट फ़ेल; 1,200 पर 7.9 s और 4.8%। Application server CPU 75%, डेटाबेस कनेक्शन 50 में से 50। 150 रिक्वेस्ट प्रति सेकंड का हेडरूम लक्ष्य पूरा नहीं हुआ, इसलिए registration के दिन पिछले semester जैसा हाल दोहराने का जोखिम है।" रन का डेटा और सर्वर ग्राफ़ संलग्न करें। Fix के बाद वही stepped टेस्ट उसी स्क्रिप्ट, डेटा और एनवायरनमेंट के साथ चलाएँ और इस रन से तुलना करें (confirmation testing); फिर 100 और 150 रिक्वेस्ट प्रति सेकंड पर 30 मिनट का लोड टेस्ट, 150 रिक्वेस्ट प्रति सेकंड से ऊपर स्ट्रेस टेस्ट, स्पाइक, स्केलेबिलिटी की तुलना और सोक टेस्ट। उन्हें अभी चलाने से वे बस उसी सीमा से फिर टकराएँगे।

अगर आपके जवाब अलग हैं, तो जाँचें कि हर लक्ष्य में लोड, परसेंटाइल और एरर रेट है, कि आपके वर्चुअल यूज़र के हिसाब में थिंक टाइम शामिल है, और कि आपने रिस्पॉन्स टाइम के साथ थ्रूपुट और रिसोर्स वाले कॉलम भी पढ़े। कोई दूसरा बजट, जैसे p95 1 s से कम, सहमति होने पर ठीक है; जो निष्कर्ष सपाट थ्रूपुट या भरे हुए कनेक्शन पूल को नज़रअंदाज़ करे, वह ठीक नहीं।