HTTP रिक्वेस्ट की लोड टेस्टिंग

HTTP रिक्वेस्ट नोड अपनी रिक्वेस्ट कई बार भेज सकता है, प्रति सेकंड रिक्वेस्ट की एक प्रोफ़ाइल के अनुसार, कई एक साथ — और जो वापस आता है उसे माप सकता है: लेटेंसी के पर्सेंटाइल, त्रुटियाँ, वह दर जहाँ तक वह पहुँचा। थ्रेशोल्ड तय करते हैं कि चरण सफल होता है या नहीं, और तुलना करें आँकड़ों को किसी पिछले रन के आँकड़ों के बगल में रखता है।

लोड नोड की एक सेटिंग है, अपने आप में कोई नोड नहीं: प्रयोग का बाकी हिस्सा — एमुलेटर, बाधा रिले, दूसरी शाखाएँ — उसके आसपास सामान्य रूप से चलता है।

रिक्वेस्ट को लोड के तहत रखना

1. एक HTTP रिक्वेस्ट नोड चुनें और उसकी रिक्वेस्ट भरें।
2. उसके गुणों में लोड के तहत भेजें चालू करें।
3. एक प्रोफ़ाइल और उसकी संख्याएँ चुनें। उनके नीचे का चार्ट, समय के साथ दर, दर को बनाता है और बताता है कि कुल कितनी रिक्वेस्ट, कितने सेकंड में होंगी।
4. एक साथ सेट करें — एक साथ कितनी रिक्वेस्ट रास्ते में हो सकती हैं।
5. थ्रेशोल्ड जोड़ें या बदलें।
6. प्रयोग चलाएँ।

लोड शुरू में एक रैंप होता है, 30,000 ms में 0 से 100 रिक्वेस्ट प्रति सेकंड तक, एक साथ 32, दो थ्रेशोल्ड के साथ: p95 < 500 ms और त्रुटियाँ < 1 %।

लोड, दोहराव और पुनः प्रयास की जगह लेता है। इसे चालू करने से वे बंद हो जाते हैं, और जिस नोड में लोड और उनमें से कोई भी हो, वह अस्वीकार किया जाता है (node.load_alone): विफल रिक्वेस्ट गिनी जाती है, दोबारा आज़माई नहीं जाती। केवल HTTP रिक्वेस्ट ही लोड के तहत चल सकती है (node.load_unsupported)।

रिक्वेस्ट एक बार पढ़ी जाती है। उसके टेम्पलेट चरण शुरू होते ही हल किए जाते हैं, इसलिए लोड की हर रिक्वेस्ट एक ही होती है: {{counter}} और {{uuid}} सभी के लिए एक ही मान लेते हैं। देखें टेम्पलेट।

पूरे लोड के लिए एक क्लाइंट। रिक्वेस्ट के बीच कुकी रखें चालू होने पर रिक्वेस्ट रन का कुकी जार साझा करती हैं, और एक ही Digest मेमोरी भी, इसलिए एक ही चैलेंज सबका जवाब बन जाता है। हर रिक्वेस्ट का टाइमआउट नोड का अपना होता है।

इंस्पेक्टर को एक नमूना मिलता है: हर 100 ms में अधिकतम एक आदान-प्रदान, ताकि लोड इंस्पेक्टर को भर न दे।

प्रोफ़ाइल

प्रोफ़ाइल	सेटिंग्स	समय के साथ दर
स्थिर	दर, req/s, अवधि, ms	पूरे समय वही दर
रैंप	शुरुआती दर, req/s, अंतिम दर, req/s, अवधि, ms	एक दर से दूसरी दर तक सीधी रेखा में
सीढ़ियाँ	शुरुआती दर, req/s, सीढ़ी, req/s, हर सीढ़ी, ms, सीढ़ियाँ	पहली दर, फिर हर स्तर पर एक सीढ़ी ऊपर, हर स्तर उतने ही समय के लिए
स्पाइक	आधार, req/s, शिखर, req/s, स्पाइक का समय, ms, स्पाइक की अवधि, ms, अवधि, ms	आधार दर, किसी तय क्षण से कुछ देर के लिए शिखर, फिर दोबारा आधार दर
रैंडम	दर, req/s, अवधि, ms	रैंडम आगमन, दर औसत के रूप में

आकार बदलने पर वह बना रहता है जो आगे ले जाया जा सकता है: यह कितनी देर चलता है और सबसे ऊँची दर जहाँ तक यह पहुँचता है।

सीमाएँ

सेटिंग	सीमा
स्थिर और रैंडम की दर, req/s, शिखर, req/s	0.1–1,00,000 रिक्वेस्ट/s
शुरुआती दर, req/s, अंतिम दर, req/s, आधार, req/s	0–1,00,000 रिक्वेस्ट/s
सीढ़ियाँ का हर स्तर, अंतिम मिलाकर	0–1,00,000 रिक्वेस्ट/s; सीढ़ी ऋणात्मक हो सकती है
अवधि, ms, हर सीढ़ी, ms	100–3,00,000 ms
सीढ़ियाँ	1–100, और सभी स्तर मिलाकर अधिकतम 3,00,000 ms
स्पाइक	0 ms से लंबा, और अवधि के अंत तक समाप्त
एक साथ	1–512
थ्रेशोल्ड	अधिकतम 16, हर मान एक संख्या, 0 या अधिक

जिस प्रोफ़ाइल से कुल मिलाकर एक भी रिक्वेस्ट नहीं बनती, वह अस्वीकार की जाती है (load.nothing_planned)। दरें वही हैं जो HTTP बर्स्ट की हैं।

प्रोफ़ाइल पूरे रन जितनी, 300 s, लंबी हो सकती है — लेकिन रन की समय सीमा हर चरण को गिनती है, इसलिए प्रयोग के बाकी हिस्से के लिए जगह छोड़ें।

कितनी रिक्वेस्ट

किसी प्रोफ़ाइल की रिक्वेस्ट उसकी दर का समय के साथ जोड़ होती हैं:

प्रोफ़ाइल	रिक्वेस्ट
स्थिर, 100/s, 1000 ms तक	100
रैंप, 0 → 100/s, 2000 ms में	100
सीढ़ियाँ, 10/s से 10/s बढ़ते हुए, 1000 ms के 3 स्तर	60 (10 + 20 + 30)
स्पाइक, 10/s, 1000 ms से 500 ms तक 100/s, कुल 2000 ms	65
रैंडम, 200/s, 10,000 ms तक	औसतन 2000

शेड्यूल

n-वीं रिक्वेस्ट उस क्षण के लिए तय होती है जब प्रोफ़ाइल की गिनती n तक पहुँचती है — पहली तुरंत। हर क्षण लोड की शुरुआत से गिना जाता है, इसलिए देर से जागना उसके बाद की रिक्वेस्ट को कभी आगे नहीं खिसकाता, और प्रोफ़ाइल जो दर बताती है, वही दर माँगी जाती है।

रैंडम आगमनों के बीच के अंतराल रन के सीड से रैंडम रूप से निकालता है: एक ही सीड से वही क्षण मिलते हैं, इसलिए रैंडम लोड को भी ठीक-ठीक दोहराया जा सकता है। देखें सीड।

छूटी रिक्वेस्ट। एक साथ अधिकतम एक साथ रिक्वेस्ट रास्ते में होती हैं। जब उनमें से हर एक अभी भी अपने जवाब की प्रतीक्षा में हो, तो अगली रिक्वेस्ट किसी ख़ाली स्लॉट की प्रतीक्षा करती है। अगर वह अपने क्षण से 50 ms से ज़्यादा देर से निकलती, तो उसे देर से नहीं भेजा जाता: उसे छोड़ दिया जाता है और छूटी हुई गिना जाता है, इस बीच तय हुई हर दूसरी रिक्वेस्ट के साथ, और लोड उस पहली रिक्वेस्ट से आगे बढ़ता है जो अभी भी समय पर है। बहुत सारी छूटी रिक्वेस्ट का अर्थ है कि सर्वर, या एक साथ, प्रोफ़ाइल के साथ नहीं चल सका।

चलते समय

हर सेकंड टाइमलाइन चरण को लोड के तहत के रूप में दिखाती है: बीते सेकंड, भेजी गई रिक्वेस्ट, पिछले सेकंड की दर, अब तक का p95 और विफल रिक्वेस्ट। रोकें लोड को तुरंत समाप्त करता है और रास्ते में चल रही रिक्वेस्ट छोड़ देता है; किसी दूसरी शाखा की विफलता इसे एक सेकंड के भीतर समाप्त कर देती है।

क्या मापा जाता है

अंतिम जवाब के बाद चरण के पास उसके माप होते हैं, जो उसकी अंतिम टाइमलाइन घटना में और रन रिपोर्ट में रखे जाते हैं:

माप	क्या
planned	प्रोफ़ाइल से कुल मिलाकर बनने वाली रिक्वेस्ट (रैंडम: औसतन)
sent	वे रिक्वेस्ट जिनका जवाब आया या जो विफल हुईं
ok	2xx स्टेटस के साथ जवाब मिला
failed	कोई और स्टेटस, या कोई जवाब ही नहीं
missed	तय समय पर हर स्लॉट व्यस्त था, इसलिए छोड़ दी गईं
rps	प्रति सेकंड भेजी गई रिक्वेस्ट: sent ÷ प्रोफ़ाइल की अवधि — या ÷ अंतिम रिक्वेस्ट निकलने तक का समय, अगर वह बाद में था
error_rate	failed, sent के % में
min, mean, max	सबसे तेज़, औसत और सबसे धीमी रिक्वेस्ट, ms
p50, p90, p95, p99	वह लेटेंसी जिस पर या जिससे कम में 50, 90, 95 और 99 % रिक्वेस्ट थीं, ms
received_bytes	कुल प्राप्त बॉडी बाइट
statuses	स्टेटस के अनुसार रिक्वेस्ट (200, 503) और, स्टेटस न होने पर, कारण के अनुसार (timeout, refused, reset …)
seconds	प्रोफ़ाइल का हर सेकंड: भेजी गई रिक्वेस्ट, विफल, उनकी औसत लेटेंसी
histogram	लेटेंसी के अनुसार रिक्वेस्ट, 1, 2, 5, 10, 20, 50, 100, 200, 500, 1000, 2000, 5000, 10,000 ms तक, और उससे धीमी

किसी रिक्वेस्ट की लेटेंसी उसे भेजने से लेकर उसका पूरा जवाब पढ़ लेने तक की होती है, और विफल रिक्वेस्ट विफल होने में लगे समय के साथ गिनी जाती है। पर्सेंटाइल 1 % चौड़े लॉगरिद्मिक बकेट से पढ़े जाते हैं और वास्तविक मान से 0.5 % के भीतर होते हैं, लोड चाहे कितनी भी देर चले।

थ्रेशोल्ड

थ्रेशोल्ड मीट्रिक, तुलना और मान की एक पंक्ति है; थ्रेशोल्ड एक जोड़ता है।

मीट्रिक	किसमें
p50, p90, p95, p99	ms
औसत, सबसे धीमा	ms
त्रुटियाँ	भेजी गई रिक्वेस्ट का %
दर	हासिल की गई प्रति सेकंड रिक्वेस्ट
छूटे	रिक्वेस्ट

तुलना इनमें से एक है: <, ≤, >, ≥। कुछ आम उदाहरण:

मीट्रिक	तुलना	मान	चरण कब विफल होता है
p95	<	300	बीस में से एक या अधिक रिक्वेस्ट में 300 ms या उससे ज़्यादा लगे
त्रुटियाँ	<	1	1 % या अधिक रिक्वेस्ट विफल हुईं
दर	≥	180	सर्वर प्रति सेकंड 180 रिक्वेस्ट नहीं ले सका
छूटे	≤	0	एक भी रिक्वेस्ट छोड़नी पड़ी

फ़ाइल में थ्रेशोल्ड { "metric": "p95_ms", "op": "lt", "value": 300 } होता है; मीट्रिक हैं p50_ms, p90_ms, p95_ms, p99_ms, mean_ms, max_ms, error_rate, rps और missed, तुलनाएँ lt, le, gt और ge।

थ्रेशोल्ड अंतिम जवाब के बाद, अपने क्रम में, पढ़े जाते हैं। चरण पहले ऐसे थ्रेशोल्ड पर विफल होता है जो पूरा नहीं होता (load.threshold), और उसका संदेश थ्रेशोल्ड और मापा गया मान बताता है; इसके साथ रन भी विफल होता है। थ्रेशोल्ड के बिना लोड सफल होता है, उसने चाहे जो मापा हो। जब किसी दूसरी शाखा की विफलता ने लोड को जल्दी समाप्त कर दिया, तो रन की विफलता वही है, कोई थ्रेशोल्ड नहीं।

परिणाम

चरण सफल होने पर टाइमलाइन उसका सार बताती है: रिक्वेस्ट, दर, p95 और विफल हिस्सा। नोड चुनें: उसके गुण पिछले रन का लोड दिखाते हैं —

• हर थ्रेशोल्ड, ✓ पूरा हुआ या ✕ पूरा नहीं हुआ, मापे गए मान के साथ;
• भेजे गए, Req/s, त्रुटियाँ अपने हिस्से के साथ, छूटे;
• p50, p90, p95, p99, औसत, अधिकतम;
• हर सेकंड: हर सेकंड की रिक्वेस्ट, विफल लाल रंग में, और उनकी औसत लेटेंसी एक रेखा के रूप में;
• लेटेंसी: कितनी रिक्वेस्ट में कितना समय लगा;
• स्टेटस और कारण, हर एक अपनी गिनती के साथ।

कमांड लाइन यही आँकड़े और हर थ्रेशोल्ड का निर्णय छापती है; देखें signallab run।

दो रन की तुलना

1. प्रयोग को दो बार, या अधिक, चलाएँ।
2. टाइमलाइन में तुलना करें दबाएँ। यह तब दिखता है जब कोई रन अपनी रिपोर्ट सहेज चुका हो, और रन चलते समय निष्क्रिय रहता है।
3. नवीनतम रन बाद में है, उससे पहले वाला पहले; किसी भी सूची से दूसरा रन चुना जा सकता है।

सूचियों में इस प्रयोग के — उसके नाम के अनुसार — रन होते हैं, डेटा फ़ोल्डर की रिपोर्टों से, सबसे नया सबसे ऊपर, अधिकतम 50: हर एक अपनी तारीख़ और समय, वह कैसे समाप्त हुआ और अपने सीड के साथ। कमांड लाइन के रन भी वहाँ होते हैं, अगर उसने वही डेटा फ़ोल्डर उपयोग किया हो। प्रयोग का नाम बदलने से नया इतिहास शुरू होता है।

हर लोड चरण के लिए, नोड के अनुसार मिलाकर, एक तालिका हर मीट्रिक को पहले, बाद में और बदलाव के साथ दिखाती है, इकाई में और % में। ग़लत दिशा में 5 % या अधिक का बदलाव — धीमा, ज़्यादा त्रुटियाँ, ज़्यादा छूटी रिक्वेस्ट, कम दर — एक रिग्रेशन है और लाल रंग में दिखता है; कुछ नहीं से कुछ होना भी गिना जाता है। तालिका के नीचे दोनों रन में हर थ्रेशोल्ड का निर्णय होता है। जो लोड चरण केवल एक रन में है, उस पर बिना बदलाव के केवल पहले या केवल बाद में का निशान होता है। बिना लोड चरण वाले रन इन रनों में कोई लोड चरण नहीं दिखाते हैं।

स्क्रिप्ट से, experiment_runs रन की सूची देता है और experiment_compare दो रन की, उनकी रिपोर्ट के फ़ाइल नाम से, तुलना करता है; signallab mcp यही असिस्टेंट को देता है (MCP)।

लोड के बाद जाँच

लोड अपना कोई रिस्पॉन्स नहीं छोड़ता: इसे मापा जाता है, जाँचा नहीं जाता। उसके बाद की किसी जाँच या मान निकालें को हर पथ पर अपने से पहले बिना लोड वाली एक और रिक्वेस्ट चाहिए, वरना प्रयोग नहीं चलता (graph.needs_http)। लोड के तहत API के किसी एक जवाब को जाँचने के लिए लोड के बाद, या उसके बगल की किसी समानांतर शाखा में, एक सादा HTTP रिक्वेस्ट रखें।

लोड के तहत किसी नोड पर अभी भेजें उसकी रिक्वेस्ट एक बार भेजता है।