Session Replay और Load Testing
कैप्चर की गई किसी रिक्वेस्ट को बिल्कुल वैसा ही दोबारा चलाया जा सकता है, दो मोड्स में जो अपना-अपना काम करते हैं: session replay एक श्रृंखला की रिक्वेस्ट्स को बल्क में, उनके मूल क्रम में दोबारा चलाता है (किसी फ़्लो को रिप्रोड्यूस करना, regression-verify करना, किसी अलग एनवायरनमेंट के खिलाफ़ रीप्ले करना); load testing किसी एक रिक्वेस्ट पर उच्च-आवृत्ति दबाव डालता है यह जांचने के लिए कि वह टिक पाता है या नहीं। दोनों कैप्चर रिकॉर्ड्स से right-click के ज़रिए उपलब्ध हैं, और यहां तक कि जो प्राइवेट APIs signature / timestamp ले जाते हैं वे भी बिना किसी दिक्कत के चलते हैं।
1. “दोबारा भेजने” के तीन तरीके, हर एक का अपना काम
Section titled “1. “दोबारा भेजने” के तीन तरीके, हर एक का अपना काम”कैप्चर की गई रिक्वेस्ट को दोबारा भेजने का एक जैसा विचार, उद्देश्य के अनुसार बांटा गया:
| क्षमता | भूमिका |
|---|---|
| Compose और Replay | किसी एक रिक्वेस्ट को एडिट करके दोबारा भेजना |
| Session replay (इस पेज का पहला भाग) | कई रिक्वेस्ट्स को क्रम में बल्क में रीप्ले करना, हर एक का status और latency देखते हुए |
| Load testing (इस पेज का दूसरा भाग) | किसी एक रिक्वेस्ट पर उच्च-आवृत्ति दबाव, throughput और latency percentiles मापते हुए |
2. Session Replay: रिक्वेस्ट्स की एक श्रृंखला को बल्क में रिप्रोड्यूस करना
Section titled “2. Session Replay: रिक्वेस्ट्स की एक श्रृंखला को बल्क में रिप्रोड्यूस करना”कैप्चर की गई रिक्वेस्ट्स की एक श्रृंखला लें और उन्हें उनके मूल क्रम में बल्क में दोबारा चलाएं, रिक्वेस्ट क्रम को faithfully रिप्रोड्यूस करते हुए, पूरी श्रृंखला को N बार loop करने के विकल्प के साथ।
वहां कैसे पहुंचें
- कैप्चर से शुरू करें: कैप्चर लिस्ट में “इस रिक्वेस्ट को रीप्ले करें” पर right-click करें, या कई को चुनकर “चुनी गई रिक्वेस्ट्स को रीप्ले करें”।
- मैन्युअल रूप से जोड़ें: पैनल में “+ रिक्वेस्ट जोड़ें”, जहां हर एक को वहीं एडिट किया जा सकता है, method / URL / parameters / headers / Body।
कॉन्फ़िगर करने योग्य
- Loop count: पूरी सीक्वेंस को N बार चलाएं।
- Request interval: हर एक के बीच कुछ देर रुकें।
- Environment switch: एक environment चुनें और एक क्लिक में पूरी श्रृंखला को किसी अलग environment के खिलाफ़ रीप्ले करें।
परिणाम: हर रिक्वेस्ट का method, URL, status code और latency सूचीबद्ध करें, साथ ही कुल प्रगति, सफलता / विफलता की संख्या, और कुल बीता समय।
कब उपयोग करें
- किसी मल्टी-स्टेप फ़्लो या timing-dependent समस्या को रिप्रोड्यूस करना।
- एंडपॉइंट्स के किसी समूह को वेरिफाई करने के लिए बैच regression।
- प्रोडक्शन से कैप्चर की गई रिक्वेस्ट्स के किसी हिस्से को जैसा है वैसा किसी टेस्ट एनवायरनमेंट के खिलाफ़ रीप्ले करना।
3. Load Testing: किसी एक रिक्वेस्ट को सीमा तक धकेलना
Section titled “3. Load Testing: किसी एक रिक्वेस्ट को सीमा तक धकेलना”किसी एंडपॉइंट को कैप्चर कर लिया और जानना चाहते हैं कि वह टिक पाता है या नहीं? किसी भी कैप्चर की गई रिक्वेस्ट पर “इस रिक्वेस्ट को load-test करें” पर right-click करके तुरंत शुरू करें, throughput और latency percentiles रीयल-टाइम में रिपोर्ट होते हैं।
दो एंट्री पॉइंट्स
Section titled “दो एंट्री पॉइंट्स”- कैप्चर रिकॉर्ड से सीधे load-test करें: “इस रिक्वेस्ट को load-test करें” पर right-click करें, और method / address / headers / body अपने आप कैरी हो जाते हैं और यह तुरंत शुरू हो जाता है, जो भी प्रोटोकॉल छूटा हो वह अपने आप भर दिया जाता है।
- मैन्युअल कॉन्फ़िगरेशन: toolbox से “Load test” खोलें और खुद टारगेट व parameters भरें। यह एक फ़्लोटिंग विंडो है, और आप कई अलग-अलग load tests को कई विंडोज़ में एक साथ चला सकते हैं, बिना एक-दूसरे में बाधा डाले।
सामान्य load-test टूल्स से अलग: यहां आप किसी कैप्चर की गई रिक्वेस्ट पर right-click करके उसे load-test कर सकते हैं, parameters दोबारा डालने की ज़रूरत नहीं, जिससे आपको “पहले कहीं और कैप्चर करना, फिर उसे हाथ से load-test टूल में ले जाना” के चक्कर से बचाया जाता है।
दो मोड्स
Section titled “दो मोड्स”- Constant rate (QPS): कॉन्फ़िगर की गई requests per second पर समान रूप से दबाव डालता है, एक अधिक सख्त latency माप पद्धति का उपयोग करते हुए, ताकि p99 जैसी tail latencies उच्च लोड में भी सही रहें, कृत्रिम रूप से कम न दिखें, “इस एंडपॉइंट की X QPS पर असली latency” आंकने के लिए उपयुक्त। यह सख्ती मुख्यतः इसी मोड पर लागू होती है।
- Concurrency: अधिकतम throughput हासिल करने के लिए एक तय concurrency पर लगातार फायर करता है, “यह कितना झेल सकता है इसकी सीमा” टेस्ट करने के लिए उपयुक्त।
कॉन्फ़िगर करने योग्य parameters
Section titled “कॉन्फ़िगर करने योग्य parameters”- Request: method (GET / POST / PUT / PATCH / DELETE / HEAD), URL (प्रोटोकॉल वैकल्पिक, https अपने आप भर जाता है), Query parameter table, header table, body (JSON / form / raw)।
- दबाव: rate (1–100000 req/s), concurrency / connections (1–2000), duration (1–3600 सेकंड, तय कुल संख्या के बजाय duration के हिसाब से)।
- एडवांस्ड: redirects को फॉलो करना, TLS verification को स्किप करना।
- Connections: स्वचालित connection reuse (keep-alive); HTTPS targets के लिए अपने आप HTTP/2 आज़माता है।
रीयल-टाइम परिणाम
Section titled “रीयल-टाइम परिणाम”- Throughput: एक बड़ा लाइव RPS नंबर, साथ ही एक लाइव throughput लाइन चार्ट।
- गिनतियां: sent / success / errors / elapsed।
- Latency percentiles (मिलीसेकंड्स में): p50 / p90 / p95 / p99 / p99.9 / max।
- Status-code distribution: 2xx / 3xx / 4xx / 5xx / error के अनुसार रंग-कोडेड लेबल्स।
किसी भी समय रोका जा सकता है; विंडो बंद करने पर चल रहा load test अपने आप रुक जाता है।
4. उतनी ही शक्तिशाली रिक्वेस्ट एडिटिंग
Section titled “4. उतनी ही शक्तिशाली रिक्वेस्ट एडिटिंग”चाहे session replay हो या load testing, रिक्वेस्ट एडिटिंग रिक्वेस्ट कंपोज़र (Composer) जैसी ही परंपरा अपनाती है: यह environment variables और dynamic values (UUID, timestamp, nonce, Base64, MD5 / SHA, HMAC signature, URL encoding, और अधिक) को सपोर्ट करती है। इसलिए जो प्राइवेट APIs केवल signature / timestamp के साथ ही अंदर आने देते हैं, उन्हें भी बल्क में रीप्ले और load-test किया जा सकता है, बिना हाथ से signature calculate किए।
वापस प्रॉक्सी कैप्चर पर जाएं · संबंधित: Compose और Replay