मॉड्यूल 16 · परफ़ॉर्मेंस टेस्टिंग

कैपेसिटी और स्केलेबिलिटी टेस्टिंग

Mutqan Soft QA टीम द्वारा · · 19 मिनट · मध्यम

Capacity testing मापती है कि system अपने performance objectives पूरे करते हुए अधिकतम कितना load संभाल सकता है। जवाब एक number होता है, अपनी शर्तों के साथ: "चार application servers पर order API, तय request mix के लिए, p95 500 ms से कम और 0.5% से कम errors के साथ 1,450 requests per second संभालती है"। Load का एक step और बढ़ाएँ, तो कोई objective fail हो जाता है।

Scalability testing पूछती है कि resources जोड़ने पर या काम बढ़ने पर यह number कैसे बदलता है: क्या आठ servers चार से दोगुनी capacity देते हैं, और क्या database में दस गुना rows होने पर भी queries तेज़ रहती हैं? दोनों tests मिलकर capacity planning को अंदाज़ों की जगह measurements देते हैं।

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

Capacity के फ़ैसले होते ही हैं, कोई टेस्ट करे या न करे: sale के दौरान कितने servers चलाने हैं, बड़ा database कब लेना है, क्या autoscaling काफ़ी है। Measurements के बिना ये अंदाज़े हैं। कम आँका तो system peak पर असली customers के सामने fail होगा; ज़्यादा आँका तो कंपनी ऐसे servers का पैसा देगी जो कुछ नहीं जोड़ते — ठीक यही होता है जब limit database हो।

Tester का सवाल बन जाता है: "यह कितना झेल सकता है, सबसे पहले क्या ख़त्म होता है, और ज़्यादा जोड़ने से क्या मिलता है?"। Stress testing ने दिखाया कि system कहाँ टूटता है और soak testing ने कि वह लंबे समय तक टिकता है या नहीं; capacity और scalability testing टूटने से पहले की usable limit बताती हैं, और यह भी कि architecture उससे आगे बढ़ सकता है या नहीं।

Capacity: objectives पूरे करते हुए अधिकतम load

ISTQB Performance Testing syllabus capacity testing को ऐसे बताता है: यह पता करना कि system कितने users और/या transactions संभालता है जबकि वह तय performance objectives पूरे करता रहे; objectives data volume के रूप में भी लिखे जा सकते हैं। ISO/IEC 25010 capacity को performance efficiency के अंतर्गत रखता है, जिसमें concurrent users, transaction throughput और database size जैसे parameters आते हैं। इसलिए हर capacity test अपना dimension बताता है।

Capacity breaking point नहीं है। System आम तौर पर अपनी capacity से काफ़ी आगे तक जवाब देता रहता है, बस बहुत धीमे या बहुत errors के साथ। Capacity वह आख़िरी load level है जिस पर हर objective पूरा होता है; कुछ टूटने तक load बढ़ाते जाना stress testing है।

  • पहले objectives तय करें, जैसे p95 500 ms से कम और errors 0.5% से कम। इनके बिना सिर्फ़ breaking point होता है।
  • पिछले lessons का workload model इस्तेमाल करें: browsing-heavy mix और checkout-heavy mix अलग-अलग capacity देते हैं।
  • Load को बराबर steps में बढ़ाएँ और हर step को steady होने तक रोके रखें, जैसे 10 मिनट, ताकि हर step एक छोटा load test हो।
  • हर step पर record करें: throughput, p95 और p99, error rate, और CPU, memory, connections व queues का usage। पहला fail होने वाला step दिखाता है कि कौन-सा objective टूटा और कौन-सा resource ख़त्म हुआ।

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

Scalability: scale up और scale out

ISTQB Performance Testing syllabus scalability testing को ऐसे बताता है: यह जाँचना कि system बढ़ सकता है या नहीं, जैसे ज़्यादा users या ज़्यादा stored data तक, ताकि वह आज से आगे की future requirements पूरी करे, और इस दौरान न मौजूदा performance requirements तोड़े, न fail हो। ISO/IEC 25010:2023 scalability को flexibility की sub-characteristic के रूप में रखता है। व्यवहार में यह बढ़त resources जोड़कर दो में से किसी एक तरीक़े से पाई जाती है।

Vertical scaling (scale up) एक server को ज़्यादा CPU, memory या तेज़ storage देती है: code नहीं बदलता, लेकिन एक छत होती है, resize में अक्सर restart लगता है, और server single point of failure बना रहता है। Horizontal scaling (scale out) load balancer के पीछे और instances, यानी application की एक जैसी copies, जोड़ती है: कोई तय छत नहीं, लेकिन instances का stateless होना ज़रूरी है (user session किसी एक instance की memory में न रखा जाए), और database या rate-limited third-party API जैसे shared हिस्से instances के साथ नहीं बढ़ते।

Scalability test वही capacity test कई sizes पर चलाता है और हर बार एक ही चीज़ बदलता है: 1, 2, 4 और 8 instances, या 4, 8 और 16 vCPU (virtual processor cores), वही data, mix और objectives रखकर। Sizes की तुलना scaling efficiency से करें, efficiency = C(N) / (N × C(1)), जहाँ C(N) N units पर capacity है; 100% का मतलब है कि हर unit अपना पूरा हिस्सा जोड़ती है।

  • Scale up: जाँचें कि software नए resources इस्तेमाल करता है। Fixed thread pool, यानी worker threads की तय संख्या जो एक साथ requests serve करते हैं, जोड़े गए cores को idle छोड़ सकता है।
  • Scale out: जाँचें कि request दूसरे instance पर पहुँचने पर session बना रहता है और scheduled jobs हर instance पर एक-एक बार नहीं चलते।
  • Data के साथ scaling: test को अगले साल के अनुमानित data volume पर दोहराएँ। जो query दस लाख rows पर तेज़ है, वह दो करोड़ rows पर शायद तेज़ न रहे।

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

Worked example: seasonal sale से पहले order API

एक online store को सालाना sale के दौरान अपनी order API पर 1,800 requests per second के peak का अनुमान है। Objective है: तय request mix के लिए p95 500 ms से कम और errors 0.5% से कम। Test environment production जैसा है: load balancer के पीछे 4 vCPU वाले application instances, 8 vCPU वाला एक database server और production जितना data। Team ने stepped capacity test 1, 2, 4, 6 और 8 instances पर चलाया।

  • 4 instances तक API लगभग linear तरीके से scale out होती है: limit application tier है।
  • 4 से 8 instances तक capacity सिर्फ़ 80 req/s बढ़ती है, जबकि database CPU 98% तक पहुँचता है और उसका connection pool भर जाता है: bottleneck database पर चला गया है।
  • यह architecture लगभग 1,500 req/s पर रुक जाता है, forecast से कम, और application instances की कोई भी संख्या यह gap नहीं भर सकती। Finding है "database को scale करें या उसका load घटाएँ", न कि "servers जोड़ें"।
  • अगला experiment: database को ज़्यादा resources या कम काम दें, जैसे कोई missing index जोड़कर या product reads को cache करके, फिर 4, 6 और 8 instances वाले runs दोहराएँ।
Objective: p95 < 500 ms and errors < 0.5 % (agreed request mix)

Instances  Capacity (req/s)  Efficiency  Saturated first
    1             400           100 %    app CPU 92 %
    2             780            98 %    app CPU 90 %
    4           1,450            91 %    DB CPU 88 %
    6           1,520            63 %    DB CPU 97 %
    8           1,530            48 %    DB CPU 98 %, DB pool full

Efficiency = capacity / (instances x 400)
Forecast peak for the sale: 1,800 req/s

Scaling curve को पढ़ना

Capacity को units की संख्या के सामने plot करें और perfect scaling की सीधी रेखा से तुलना करें। Curve का आकार बताता है कि आगे क्या करना है।

  • Linear: हर unit अपना पूरा हिस्सा जोड़ती है। जब तक shared हिस्से साथ दें, capacity और units लेकर ख़रीदी जा सकती है।
  • Sub-linear: coordination और shared resources की वजह से हर unit थोड़ा कम जोड़ती है। Scaling काम करती है, लेकिन हर request महँगी पड़ती है।
  • Plateau: capacity का बढ़ना रुक जाता है, जैसे worked example में। कोई shared component saturated है; उसे खोजें और scale करें, क्योंकि और units सिर्फ़ cost बढ़ाती हैं।
  • Retrograde: units जोड़ने पर capacity घटती है, अक्सर इसलिए कि instances किसी lock या connection pool के लिए होड़ करते हैं। इसे defect के रूप में report करें।
Application instances के सामने capacity के चार आकार: linear और sub-linear बढ़त 1,800 req/s का forecast पार करती है, जबकि example की order API database saturate होते ही लगभग 1,530 req/s पर ठहर जाती है। वैचारिक मॉडल
  1. Linearहर instance 400 req/s जोड़ता है (efficiency लगभग 100%): 5 instances पर forecast पूरा होता है।

    संदर्भ रेखा:अनुमानित peak: 1,800 req/s

  2. Sub-linearहर instance थोड़ा कम जोड़ता है (8 पर efficiency 72%): 6 instances 1,860 req/s देते हैं, प्रति request ज़्यादा cost पर।

    संदर्भ रेखा:अनुमानित peak: 1,800 req/s

  3. Plateau: order API4 instances तक लगभग linear, फिर database saturate होने पर लगभग 1,530 req/s पर सपाट: कोई instance count forecast तक नहीं पहुँचता।

    संदर्भ रेखा:अनुमानित peak: 1,800 req/s

  4. Retrograde4 instances के बाद capacity घटती है, क्योंकि instances किसी lock या connection pool के लिए होड़ करते हैं: ज़्यादा resources हालत बिगाड़ते हैं।

    संदर्भ रेखा:अनुमानित peak: 1,800 req/s

    ज़्यादा instances, कम capacity

Linear, sub-linear और retrograde curves सिर्फ़ उदाहरण हैं; plateau worked example के मापे गए numbers इस्तेमाल करता है। चारों plots एक ही scales पर हैं।

Test results से capacity plan तक

Capacity planning तय करती है कि अनुमानित demand को safety margin के साथ संभालने के लिए कितना infrastructure चाहिए और कब तक। Google SRE book बताती है कि इसके लिए क्या ज़रूरी है: ऐसा demand forecast जो organic growth और launches व campaigns जैसी inorganic घटनाओं को शामिल करे और capacity जोड़ने में लगने वाले समय से आगे तक देखे, और नियमित load testing जो raw capacity (servers, disks) को service capacity से जोड़े।

Tester यह दूसरा हिस्सा capacity statement के रूप में देता है: "तय mix के लिए हर 4 vCPU instance पर 400 req/s, 4 instances तक लगभग linear; database CPU saturate होने के कारण architecture लगभग 1,500 req/s पर रुक जाता है"।

  • Headroom: peak पर production को tested capacity से कितना नीचे रहना चाहिए। यह team का फ़ैसला है; 80% की सीमा के साथ 1,800 req/s के forecast को 2,250 req/s की tested capacity चाहिए।
  • Spare units: calculation से एक instance ज़्यादा (N+1), ताकि एक के गिरने पर भी पर्याप्त capacity बची रहे।
  • Lead time: autoscaled instance जोड़ने में मिनट, बड़े database के लिए शायद हफ़्ते। सबसे धीमा resource तय करता है कि plan को कितनी जल्दी शुरू होना है।
  • Production thresholds: ISTQB syllabus कहता है कि scalability limits पता चलने के बाद production में thresholds monitor किए जा सकते हैं, जैसे database CPU 75% पार करे तो alert।

आम गलतियाँ

  • Breaking point को capacity बताना। Capacity वह आख़िरी load है जो हर objective पूरा करता है, और यह उस load से काफ़ी कम है जिस पर errors तेज़ी से बढ़ने लगते हैं।
  • Capacity को उसकी शर्तों के बिना बताना। "System 1,500 users संभालता है" का request mix, data volume, server sizes और objectives के बिना कोई मतलब नहीं।
  • Linear scaling मान लेना: कई sizes मापने की बजाय एक instance के result को गुणा कर देना।
  • Runs के बीच कई चीज़ें एक साथ बदलना, जैसे instance count और code version, जिससे capacity में बदलाव समझाया न जा सके।
  • छोटे या लगभग खाली database पर scale out टेस्ट करना, जहाँ shared components कभी limit बनते ही नहीं।
  • सिर्फ़ application servers देखना। Database और connection-pool metrics के बिना plateau दिखता है, उसका कारण नहीं।

QA का नज़रिया

Capacity और scalability tests developers और operations (DevOps या SRE) के साथ plan होते हैं, क्योंकि इन्हें production जैसा environment, monitoring और अक्सर budget चाहिए। Tester objectives, workload model और step plan लाता है, और जाँचता है कि environment और data representative हैं। शुरुआत में पूछें: हम किस forecast के लिए plan कर रहे हैं, कौन-से resources बदल सकते हैं, और capacity कितनी जल्दी जोड़ी जा सकती है?

Report में शर्तों के साथ capacity statement, हर configuration की efficiency और पहले saturate होने वाले resource वाली table, और एक recommendation दें। साफ़ लिखें कि test environment production से कहाँ अलग है। Scripts और data संभालकर रखें ताकि architecture बदलाव, बड़े releases या data में बड़ी बढ़त के बाद test दोहराया जा सके: capacity बदलता हुआ number है।

अभ्यास

Vertical scaling result पढ़ें और अगला step तय करें

आपका काम

एक product search service को एक instance पर चार sizes में, वही data और request mix रखकर, टेस्ट किया गया। उसका objective है p95 300 ms से कम और errors 1% से कम। आँकें कि वह कितनी अच्छी तरह scale up होती है और forecast के लिए कितनी capacity चाहिए, फिर अगले test की सिफ़ारिश करें।

सामग्री
Service: product search, one instance, same data and request mix
Objective: p95 < 300 ms and errors < 1 %

vCPU  Capacity (req/s)  CPU at capacity  Thread pool at capacity
  2         250              95 %            38 of 64 busy
  4         480              93 %            61 of 64 busy
  8         610              58 %            64 of 64 busy
 16         620              31 %            64 of 64 busy

Forecast peak next quarter: 900 req/s
Team policy: peak load stays at or below 80 % of tested capacity
चरण
  1. हर size की scaling efficiency 2 vCPU के सापेक्ष निकालें।
  2. पता करें कि scale up कहाँ फ़ायदेमंद नहीं रहता, और क्यों।
  3. Team policy के तहत forecast के लिए ज़रूरी tested capacity निकालें।
  4. एक capacity statement और अगला test लिखें।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

2 vCPU के सापेक्ष efficiency: 4 vCPU = 480 ÷ (2 × 250) = 96%; 8 vCPU = 610 ÷ (4 × 250) = 61%; 16 vCPU = 620 ÷ (8 × 250) = 31%।

Scale up 4 vCPU तक फ़ायदेमंद है, फिर रुक जाता है। 8 और 16 vCPU पर CPU saturation से बहुत दूर है (58% और 31%) जबकि सभी 64 threads busy हैं: fixed thread pool concurrent काम को सीमित करता है, इसलिए extra cores idle रहते हैं।

ज़रूरी tested capacity: 900 ÷ 0.8 = 1,125 req/s। सबसे अच्छा single instance 620 req/s तक पहुँचा, इसलिए एक instance का कोई भी tested size forecast पूरा नहीं करता।

Statement: "Product search, एक instance, मौजूदा data और तय mix: 4 vCPU पर 480 req/s, 8 या 16 vCPU पर लगभग 620 req/s; 4 vCPU से ऊपर limit CPU नहीं, 64-thread pool है।" अगला: developers के साथ 8 vCPU पर thread pool बढ़ाकर test दोहराएँ, और 4 vCPU instances के साथ scale out टेस्ट करें। अगर scale out linear होता, तो तीन instances अधिकतम 3 × 480 = 1,440 req/s देते, जो 1,125 के लिए काफ़ी है, यानी spare (N+1) के साथ plan को चार instances चाहिए; पर पहले इसे मापें, क्योंकि कोई shared component worked example की तरह plateau पर पहुँच सकता है।

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

Capacity testing और stress testing में क्या फ़र्क है?

Capacity testing उस सबसे ऊँचे load पर रुकती है जहाँ हर objective अब भी पूरा होता है; stress testing जान-बूझकर उससे आगे जाती है ताकि दिखे कि system कैसे fail होता है और कैसे recover करता है। दोनों stepped ramp इस्तेमाल कर सकती हैं, लेकिन उसे अलग तरह पढ़ती हैं: capacity test का जवाब आख़िरी pass step है, breaking point नहीं।

क्या scalability testing और autoscaling की testing एक ही हैं?

नहीं। Autoscaling test, जैसा spike testing में होता है, जाँचता है कि load बढ़ने पर नए instances पर्याप्त तेज़ी से शुरू होते हैं। Scalability test जाँचता है कि वे instances सच में capacity जोड़ते हैं। ऐसा हो सकता है कि autoscaling पूरी तरह ठीक काम करे और फिर भी system scale न करे, अगर हर नया instance उसी database का इंतज़ार करता हो।

क्या मैं छोटे environment में capacity टेस्ट करके result को बड़ा कर सकता हूँ?

सिर्फ़ सावधानी से। छोटे environment में मापी गई per-instance capacity उपयोगी है, लेकिन shared components और data volume उसी अनुपात में नहीं बढ़ते, इसलिए plateau शायद production size पर ही दिखे। Report में अंतर लिखें, और इससे पहले कि ये numbers किसी purchase या launch का आधार बनें, मुख्य numbers production जितने बड़े environment में पक्के करें।

क्या capacity testing के लिए कोई ख़ास tool चाहिए?

नहीं। पिछले lessons के load tools, जैसे JMeter, k6, Gatling या Locust, सभी load को steps में बढ़ा सकते हैं। फ़र्क plan में है: stepped load, हर configuration के लिए वही run दोहराना, और server-side monitoring। Grafana k6 documentation उस test को breakpoint test कहता है जो system के fail होने तक load बढ़ाता है, और बताता है कि कुछ लोग इसे capacity testing कहते हैं। इस lesson वाले अर्थ में capacity पाने के लिए उस पहले step पर रुकें जहाँ कोई objective टूटे; k6 यह abortOnFail पर set किए गए threshold से कर सकता है।

संदर्भ

  • Certified Tester Performance Testing (CT-PT)ISTQB · 2018performance testing पर ISTQB का specialist पाठ्यक्रम: बुनियादी अवधारणाएँ, performance measurements, टेस्ट गतिविधियाँ व कार्य, और टूल।
  • ISO/IEC 25010:2023 — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality modelISO/IEC · 2023उत्पाद गुणवत्ता मॉडल: कार्यात्मक उपयुक्तता, प्रदर्शन दक्षता, संगतता, इंटरैक्शन क्षमता, विश्वसनीयता, सुरक्षा, रखरखाव-योग्यता और लचीलापन।
  • Site Reliability Engineering: How Google Runs Production SystemsGoogle / O'Reilly Media · 2016सर्विस लेवल ऑब्जेक्टिव, एरर बजट, "चार गोल्डन सिग्नल" की निगरानी और ओवरलोड संभालना — लचीलेपन का परिचालन पक्ष।
  • Load test types — Grafana k6 documentationGrafana Labsआम load test प्रकारों की परिभाषाएँ — smoke, average-load, stress, soak, spike और breakpoint — और हर एक से क्या पता लगाना होता है।
टूल्स

Mutqan tools से अभ्यास करें

लार्ज JSON डेटासेट जनरेटर

pagination, परफ़ॉर्मेंस और parser जाँचने के लिए किसी template से बड़े JSON array (हज़ारों रिकॉर्ड) जनरेट करें।

टेस्ट डेटा

HTTP रिक्वेस्ट बेंचमार्क

किसी सार्वजनिक endpoint पर छोटा, सुरक्षित बेंचमार्क चलाएँ (सीमित रिक्वेस्ट व concurrency) और throughput तथा latency percentile पाएँ।

परफ़ॉर्मेंस

और गहराई से

इस topic में आपकी प्रगति

QA रोडमैप का हिस्सा