स्पाइक टेस्टिंग

यह क्यों ज़रूरी है

Stress test, जैसा पिछले lesson में देखा, load को अपेक्षित peak से आगे ले जाकर limit खोजता है। Spike test कुछ और पूछता है: peak शायद उतना ही हो जितना system scale होने के बाद संभाल लेता है, लेकिन वह system के react करने से पहले आ जाता है। नए instances को शुरू होने में मिनट लगते हैं, caches ठंडे होते हैं, connection pools सामान्य traffic के हिसाब से बने होते हैं, और जो request अभी serve नहीं हो सकती वह queue में इंतज़ार करती है या fail हो जाती है।

Systems अपने सबसे व्यस्त दिन इसी तरह fail होते हैं — sale, ticket release, registration की आख़िरी तारीख़ — जब खोए हुए orders और retry की गई requests से दोहरे payments सबसे महँगे पड़ते हैं। Tester के लिए spike test "हमारे पास autoscaling है" को सबूत में बदलता है: scaling lag कितना लंबा है, उस दौरान users क्या देखते हैं, और system सच में वापस आता है या नहीं।

Spike profile का आकार

Spike profile के पाँच phases होते हैं: सामान्य load पर baseline, मिनटों में नहीं बल्कि सेकंडों में मापा जाने वाला ramp, spike level पर छोटा hold, तेज़ drop, और baseline पर recovery period। Recovery period test का हिस्सा है: इसी से पता चलता है कि system सामान्य हालत में लौटता है या नहीं। Spike level और उसकी अवधि असली event से लें — किसी campaign की अपेक्षित audience, पिछले साल की sale — किसी गोल संख्या से नहीं। Grafana k6 की test-type guide spike को बिना hold या बहुत छोटे hold के साथ दिखाती है; अगर असली burst कई मिनट चलता है, जैसे flash sale में, तो spike को उतनी देर hold करें।

Load को arrival rate से चलाएँ, virtual users की तय संख्या से नहीं। उस closed model में हर virtual user अगली request भेजने से पहले अपने response का इंतज़ार करता है, इसलिए system धीमा होते ही tool कम requests भेजने लगता है और वही burst छिप जाता है जिसे आप टेस्ट करना चाहते हैं। नीचे की script एक arrival-rate executor इस्तेमाल करती है; अगर rate बनाए रखने के लिए k6 के virtual users कम पड़ जाएँ, तो वह dropped_iterations report करता है: कमी tool की है, system की नहीं।

import http from 'k6/http';

export const options = {
  scenarios: {
    flash_sale_spike: {
      executor: 'ramping-arrival-rate',
      startRate: 100,          // requests per second (one request per iteration)
      timeUnit: '1s',
      preAllocatedVUs: 500,
      maxVUs: 6000,            // enough to keep the rate when responses slow down
      stages: [
        { duration: '5m', target: 100 },   // 1 baseline
        { duration: '30s', target: 600 },  // 2 spike up
        { duration: '5m', target: 600 },   // 3 hold
        { duration: '30s', target: 100 },  // 4 drop
        { duration: '10m', target: 100 },  // 5 recovery
      ],
    },
  },
};

export default function () {
  http.get('https://staging.example.com/api/checkout/summary');
}

आज़माएँ: परफ़ॉर्मेंस टेस्ट डेटा जनरेटर आज़माएँ: Concurrent रिक्वेस्ट टेस्ट जनरेटर

Autoscaling और scaling lag

Autoscaling तब instances जोड़ता है जब कोई metric threshold पार करता है, और इसके हर कदम में समय लगता है: metric का एक window पर average लिया जाता है, rule एक schedule पर evaluate होता है, और नए instance को boot होना, warm up होना और health check पास करना होता है, तभी load balancer उसे traffic भेजता है। इन सबका जोड़ scaling lag है। जब तक यह ख़त्म न हो, पूरा burst पहले से मौजूद instances ही उठाते हैं। इसलिए spike test सिर्फ़ आख़िरी instance count नहीं, पूरी scaling chain मापता है:

• Spike शुरू होने से scale-out के फ़ैसले तक का समय, और फ़ैसले से नए instances के traffic serve करने तक का समय।
• Instances की अधिकतम संख्या, और spike उस तक पहुँचता है या नहीं।
• जो चीज़ें application के साथ scale नहीं होतीं: database connections (हर नया instance अपना pool खोलता है), third-party rate limits, एक अकेला cache node।
• बाद में scale-in: cooldown कितना है, और जब load threshold के आसपास घूमता है तो instance count ऊपर-नीचे flap करता है या नहीं।

Queues, overload और recovery

जब requests serve होने से तेज़ आती हैं, तो अंतर queue में इंतज़ार करता है: load balancer, web server, connection pool या message broker में। 400 की capacity के सामने 600 requests प्रति सेकंड पर backlog हर सेकंड 200 बढ़ता है; 30 सेकंड बाद 6,000 requests इंतज़ार में होती हैं, और हर नई request उनके पीछे लगभग 15 सेकंड रुकती है। Burst ख़त्म होने पर backlog सिर्फ़ बची हुई capacity की रफ़्तार से drain होता है, और drain का यह समय recovery का हिस्सा है।

Overload को अच्छी तरह संभालने वाला system अपनी queues छोटी रखता है और जो समय पर serve नहीं कर सकता उसे मना कर देता है — 503 Service Unavailable, जिसे RFC 9110 temporary overload के लिए परिभाषित करता है और जिसके साथ Retry-After header आ सकता है, या किसी एक client की limit के लिए 429 Too Many Requests (RFC 6585) — बजाय इसके कि requests तब तक रुकी रहें जब तक clients का timeout न हो जाए। Retries spike को और बिगाड़ते हैं: तुरंत retry करने वाले clients load कई गुना कर देते हैं, इसलिए जाँचें कि वे random jitter के साथ exponential backoff इस्तेमाल करते हैं, और script में भी यही व्यवहार model करें।

• Spike के हर मिनट में: error rate और error का प्रकार (तेज़ 503 एक सोचा-समझा जवाब है, 504 timeouts और 500 errors नहीं), p95 और p99 latency, और क्या checkout चलता रहता है जबकि कम ज़रूरी requests मना की जाती हैं।
• Message queues: अधिकतम depth और drain time, बिना कोई message खोए या दो बार process किए, और ऐसे duplicate orders नहीं जहाँ client ने पहले ही सफल हो चुकी request को retry किया।
• Recovery: latency, errors, queue depth और instance count के baseline पर लौटने तक का समय, और कुछ भी अटका न रहे।

आज़माएँ: API स्टेटस कोड सिम्युलेटर आज़माएँ: HTTP स्टेटस कोड लुकअप

Worked example: 20:00 बजे की flash sale

Staging का आकार production जैसा है: 4 instances, हर एक लगभग 100 requests प्रति सेकंड, एक ऐसे gateway के पीछे जो 10 सेकंड बाद timeout कर देता है। Autoscaler हर मिनट पिछले मिनट का average CPU देखता है; 70% से ऊपर होने पर वह 4 instances जोड़ता है, ज़्यादा से ज़्यादा 8 तक, जिन्हें तैयार होने में लगभग 2 मिनट लगते हैं, और 5 मिनट तक 30% से नीचे रहने पर उन्हें हटा देता है। हर instance के 20 database connections हैं; database 150 स्वीकार करता है। Tester ऊपर की script वाला profile checkout journey पर चलाता है, जो test orders बनाती है, 5,000 अलग-अलग test users के साथ, और मिनट-दर-मिनट नतीजों को phases के हिसाब से summarise करता है:

• Scaling lag: spike 05:00 पर शुरू हुआ और नए instances ने 08:00 पर traffic serve करना शुरू किया। इस बीच लगभग 600 requests प्रति सेकंड आती रहीं जबकि capacity 400 थी: backlog तब तक बढ़ा जब तक requests gateway के 10 सेकंड के timeout तक नहीं पहुँच गईं, p95 10 s पर टिक गया और 06:00 से एक-तिहाई requests fail हुईं। Sale का समय पहले से पता है, इसलिए team उसके शुरू होने से पहले scale out कर सकती है।
• छिपी हुई limit: 8 × 20 = 160 connections, लेकिन database 150 ही स्वीकार करता है, इसलिए scale out करने से नई errors आईं। इसे इसी हिसाब के साथ defect के रूप में report करें।
• Load shedding नहीं: requests तुरंत 503 और Retry-After के साथ मना होने की बजाय gateway के 10 सेकंड के timeout तक रुकी रहीं। 600 आने और 400 serve होने पर एक-तिहाई requests किसी भी हाल में serve नहीं हो सकती थीं; उन्हें तुरंत मना करने से queue छोटी रहती और बाक़ी दो-तिहाई तेज़ रहतीं।
• Recovery: नए instances आने के लगभग 30 सेकंड बाद backlog ख़त्म हो गया, और load घटते ही latency baseline पर लौट आई, लेकिन order-confirmation email की queue, जिसके workers scale नहीं होते, 9,000 messages तक पहुँची और drop के छह मिनट बाद, 17:00 पर ही ख़ाली हुई। पूछें कि यह देरी स्वीकार्य है या नहीं, और हर fix के बाद वही profile दोबारा चलाएँ।

Spike test, run 1 (staging sized like production)

time   arrival     instances  p95     errors  observation
00-05  100/s       4          220 ms  0%      baseline
05-06  up to 600   4          10 s    5%      CPU 100%, backlog builds, first 504 at 05:54
06:00                                         scale-out triggered: +4 instances
06-08  600/s       4          10 s    33%     504 from the gateway (10 s timeout)
08:00                                         4 new instances in service (maximum 8)
08-09  600/s       8          8.9 s   6%      backlog drains in about 30 s
09-11  600 to 100  8          450 ms  5%      DB: too many connections (160 > 150)
11-16  100/s       8          210 ms  0%      API at baseline; email queue peaks at 9,000
16-21  100/s       4          230 ms  0%      scale-in 16:00; email queue empty at 17:00

आज़माएँ: लोड टेस्ट डेटा जनरेटर

अक्सर पूछे जाने वाले सवाल

संदर्भ

• Certified Tester Performance Testing (CT-PT)ISTQB · 2018performance testing पर ISTQB का specialist पाठ्यक्रम: बुनियादी अवधारणाएँ, performance measurements, टेस्ट गतिविधियाँ व कार्य, और टूल।
• Load test types — Grafana k6 documentationGrafana Labsआम load test प्रकारों की परिभाषाएँ — smoke, average-load, stress, soak, spike और breakpoint — और हर एक से क्या पता लगाना होता है।
• Site Reliability Engineering: How Google Runs Production SystemsGoogle / O'Reilly Media · 2016सर्विस लेवल ऑब्जेक्टिव, एरर बजट, "चार गोल्डन सिग्नल" की निगरानी और ओवरलोड संभालना — लचीलेपन का परिचालन पक्ष।
• RFC 9110: HTTP SemanticsIETF · 2022HTTP मेथड, हेडर फ़ील्ड, स्टेटस कोड और कंटेंट निगोशिएशन के अर्थ, वायर वर्ज़न से स्वतंत्र।