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

परफ़ॉर्मेंस मेट्रिक्स

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

Performance metrics वे numbers हैं जो बताते हैं कि किसी तय load पर system कितनी जल्दी जवाब देता है और कितना काम पूरा करता है। पाँच metrics सबसे ज़्यादा अर्थ रखते हैं: response time (client की नज़र से एक request कितना समय लेती है), latency (कोई चीज़ कितनी देर इंतज़ार करती है या सफ़र में रहती है), throughput (हर second कितना काम पूरा होता है), error rate (काम का कितना हिस्सा fail होता है) और resource utilisation (CPU, memory, disks, network और connection pools कितने busy हैं)।

एक उदाहरण: एक checkout API, जब एक tester उसे call करता है, 290 ms में जवाब देता है। 50 requests per second पर वह अब भी 300 ms में जवाब दे सकता है, या database के connections ख़त्म होने पर 3% errors के साथ 4 seconds ले सकता है। इन दोनों में से क्या हुआ और क्यों, यह सिर्फ़ एक ही time window में साथ-साथ मापे गए metrics बताते हैं।

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

"Average response time 400 ms था" जैसा एक number एक fail होते system को छिपा सकता है। जल्दी लौटने वाले errors average को नीचे खींचते हैं, plan से कम traffic भेजने वाला load tool system को healthy दिखाता है, और पहले से 95% CPU पर चल रहे server के पास अगले peak के लिए जगह नहीं होती। "क्या हम campaign launch करें?" जैसे फ़ैसले उतने ही अच्छे होते हैं जितने उनके पीछे के metrics।

Tester के लिए metrics developers, operations और product owner के साथ साझा भाषा हैं। जो finding metric का नाम, उसे कहाँ मापा गया, किस अवधि में और किस load पर, यह सब बताती है, उस पर काम हो सकता है; "system slow है" पर नहीं।

Response time और उसके हिस्से

Response time वह समय है जो client के request शुरू करने के पल से पूरा response मिलने तक लगता है। इसे client side पर मापा जाता है, इसलिए इसमें रास्ते की हर चीज़ शामिल है: server को ढूँढना, connection खोलना, server का अपना काम और वापसी का transfer। Server logs अक्सर एक छोटी duration दर्ज करते हैं जिसमें network शामिल नहीं होता, इसलिए हर number के साथ लिखें कि उसे कहाँ मापा गया।

नए HTTPS connection पर यह नीचे दिए चार हिस्सों में बँटता है। curl अपने -w option से हर हिस्से के ख़त्म होने का पल print करता है; values शुरुआत से गिने गए seconds हैं, इसलिए हर हिस्सा दो पड़ोसी values का अंतर है। Sample में waiting 0.244 − 0.061 = 0.183 s है, कुल 0.289 s में से। अगर waiting हावी हो तो server देखें; अगर connection set-up हावी हो तो network, server की दूरी और connection reuse देखें।

  • DNS lookup: host name को IP address में बदला जाता है।
  • TCP connect और TLS handshake: connection खोला और secure किया जाता है। Reuse किया गया (keep-alive) connection दोनों को छोड़ देता है।
  • Waiting: request server तक जाती है, server उसे process करता है और response का पहला byte वापस आता है। शुरुआत से गिनने पर इस phase का अंत time to first byte (TTFB) है; k6 यही नाम सिर्फ़ waiting phase के लिए इस्तेमाल करता है।
  • Content download: बाकी response आता है। बड़ी या uncompressed body से यह हिस्सा बढ़ता है।
fmt='dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect}'
fmt="$fmt ttfb=%{time_starttransfer} total=%{time_total}\n"
curl -s -o /dev/null -w "$fmt" https://shop.example.com/api/cart

# output in seconds from the start, rounded to milliseconds:
# dns=0.012 tcp=0.030 tls=0.061 ttfb=0.244 total=0.289
curl से मापी गई एक HTTPS request: कुल 289 ms, जिनमें 61 ms connection set-up, 183 ms पहले byte का इंतज़ार और 45 ms body download।

GET /api/cart के लिए curl -w output (शुरुआत से seconds)

भाग 1:dns=0.012 भाग 2:tcp=0.030 भाग 3:tls=0.061 भाग 4:ttfb=0.244 भाग 5:total=0.289

  • 1–3Connection set-up: request भेजने से पहले 61 ms, reuse किए गए connection पर छूट जाता है
  • 1–4शुरुआत से गिना गया time to first byte, जैसे curl गिनता है: 244 ms (k6 का TTFB, http_req_waiting, लगभग सिर्फ़ part 4 है)
  • 1–5Client को दिखने वाला response time: 289 ms
  1. 1DNS lookupHost name को IP address में बदला जाता है; cached name लगभग कोई समय नहीं लेता।12 ms
  2. 2TCP connectएक round trip connection खोलता है। Reuse किया गया connection इसे छोड़ देता है।30 - 12 = 18 ms
  3. 3TLS handshakeConnection को secure करता है: TLS 1.3 में एक round trip, reuse पर यह भी छूट जाता है।61 - 30 = 31 ms
  4. 4WaitingRequest जाती है, server काम करता है और पहला byte लौटता है। धीमा server code यहीं दिखता है।244 - 61 = 183 ms
  5. 5Content downloadबाकी body आती है; यह हिस्सा response size और धीमे network के साथ बढ़ता है।289 - 244 = 45 ms

नए connection पर एक request के उदाहरण के timings। curl शुरुआत से cumulative seconds print करता है, इसलिए हर हिस्सा दो पड़ोसी values का अंतर है।

आज़माएँ: रिस्पॉन्स टाइम एनालाइज़र आज़माएँ: रिस्पॉन्स साइज़ एनालाइज़र

Latency: बताएँ कि आपका मतलब कौन-सी है

Performance के काम में latency सबसे ज़्यादा अर्थों वाला शब्द है। Networking में इसका मतलब data के सफ़र का समय है, जिसे आम तौर पर round-trip time (RTT) के रूप में बताया जाता है। कुछ load tools इसे response का पहला हिस्सा आने तक के समय के लिए इस्तेमाल करते हैं: JMeter की Latency वहीं रुकती है, जबकि उसका Elapsed time आख़िरी हिस्से तक चलता है। Google की SRE book के four golden signals latency को request service करने के पूरे समय के लिए इस्तेमाल करते हैं, जिसे यह lesson response time कहता है।

यह फ़र्क़ practice में मायने रखता है। नए HTTPS connection को पहला byte आने से पहले लगभग तीन round trips चाहिए: एक TCP handshake के लिए, एक TLS 1.3 handshake के लिए और एक खुद request के लिए। 80 ms के RTT पर यह server के अपने काम से पहले ही लगभग 240 ms है, और तेज़ server इसे नहीं हटा सकता; connection reuse set-up वाले दो round trips हटा देता है, और users के पास वाला server तीनों को छोटा कर देता है। Tools भी घड़ी अलग-अलग points पर शुरू और बंद करते हैं: k6 का http_req_duration sending, waiting और receiving का जोड़ है और TCP connecting व TLS handshaking को अलग metrics में बताता है, जबकि curl के time_total में ये शामिल हैं। Plan और report में लिखें कि हर number कौन-सी definition इस्तेमाल करता है।

आज़माएँ: API परफ़ॉर्मेंस कंपेरेटर

Throughput, error rate और resource utilisation

Response time अकेली requests को बताता है। अगले तीन metrics load के नीचे पूरे system को बताते हैं, और उनका अर्थ तभी बनता है जब उन्हें साथ में, एक ही time window में और एक ज्ञात load पर पढ़ा जाए।

  • Throughput: प्रति इकाई समय पूरा हुआ काम — requests per second (RPS), transactions per second (TPS) जब एक user action कई requests में फैला हो, या bytes per second। यह गिनता है कि system ने क्या पूरा किया, न कि load tool ने क्या भेजने की कोशिश की। JMeter जैसे load tools failed requests को भी throughput में गिनते हैं, इसलिए जब target successful काम के बारे में हो तो successes अलग गिनें। अगर load बढ़ता रहे और throughput बढ़ना बंद कर दे, तो system किसी limit पर पहुँच गया है।
  • Error rate: उसी window में fail हुई requests को सभी requests से भाग देने पर मिलने वाला अनुपात, percentage में। पहले से तय करें कि failure क्या गिना जाएगा: 5xx responses, timeouts, connection errors, और, जैसा SRE book बताती है, गलत content वाला 200 response; कुछ teams policy के तौर पर तय limit से धीमे हर response को भी failure गिनती हैं। Successful requests का response time अलग report करें, क्योंकि तेज़ errors system को असल से तेज़ दिखाते हैं।
  • Resource utilisation: हर resource कितना busy है — CPU, memory, disk, network और database connections व worker threads जैसे pools। Utilisation बताता है कि resource का कितना हिस्सा इस्तेमाल हो रहा है; saturation बताता है कि क्या काम पहले से उसके लिए queue में है। 50 में से 50 connections इस्तेमाल में हों और requests इंतज़ार में हों, तो pool saturated है, CPU graph कुछ भी दिखाए।
  • Load generator भी एक resource है: अगर उसका अपना CPU या network limit पर है, तो results system under test को नहीं, tool को बताते हैं।

आज़माएँ: HTTP रिक्वेस्ट बेंचमार्क

Worked example: दस मिनट के load run को पढ़ना

एक team staging में POST /api/orders पर दस मिनट का steady load चलाती है। Product owner के साथ तय target है: कम से कम 20 successful orders per second, 0.5% से कम error rate के साथ। नीचे का summary load tool के results को server dashboards के साथ जोड़ता है।

Summary से: successful orders का throughput 11,880 / 600 = 19.8 per second है, target से थोड़ा कम। Error rate 120 / 12,000 = 1.0% है, limit का दोगुना। Resources वजह बताते हैं: database CPU के पास अभी headroom है, लेकिन connection pool saturated है, इसलिए requests connection के लिए queue में रहती हैं जब तक उनका timeout न हो जाए या service 503 न लौटा दे। Report करने वाली finding है "20 orders per second पर connection pool ख़त्म, error rate 1.0%", इन numbers के साथ — "database slow है" नहीं।

POST /api/orders · staging · 10 minutes of steady load

Duration                   600 s
Requests sent              12,000
Successful (201 Created)   11,880
Failed                     120   (84 timeouts after 5 s, 36 x HTTP 503)
Median response time       210 ms (successful requests only)
Database CPU               55% average
DB connection pool         50 of 50 in use, up to 30 requests waiting

Vocabulary जो आपको बार-बार मिलेगी

  • Transaction: requests का नाम वाला group जिसे एक user action के रूप में मापा जाता है, जैसे "checkout", उसकी पहली request से आख़िरी response तक।
  • Virtual user (VU): load tool में एक simulated user, जो एक script को loop में चलाता है।
  • Think time: वह ठहराव जो असली user actions के बीच लेता है। इसे छोड़ देने पर 100 virtual users 100 असली लोगों से कहीं ज़्यादा traffic भेजते हैं।
  • Concurrency: एक ही पल में कितने users या requests active हैं। यह throughput नहीं है: 100 concurrent users response time और think time के हिसाब से 10 या 1,000 requests per second पैदा कर सकते हैं।
  • Percentile (p95): वह value जिसके बराबर या नीचे 95% measurements होते हैं; median p50 है, यानी बीच की value। Reports averages की जगह percentiles पर भरोसा करती हैं, और percentiles का अपना अलग lesson है।
  • SLI और SLO: service level indicator एक मापा गया metric है, जैसे 300 ms के अंदर जवाब पाने वाली requests का हिस्सा; service level objective उसके लिए तय target है।
  • Bottleneck और headroom: bottleneck वह resource है जो throughput को सबसे पहले सीमित करता है; headroom वह बची हुई capacity है जो resource के limit पर पहुँचने से पहले बाकी है।

आम गलतियाँ

  • एक average response time report करना, बिना यह बताए कि failed requests उसमें शामिल हैं या नहीं।
  • "Latency" और "response time" को एक ही number मानना, या ऐसे दो tools की तुलना करना जो घड़ी अलग points पर शुरू और बंद करते हैं।
  • Tool को जितना load भेजने के लिए configure किया गया उसे throughput मान लेना, बजाय उन requests के जो system ने सच में पूरी कीं।
  • सिर्फ़ 5xx responses को errors गिनना और timeouts, connection errors और गलत body वाले 200 responses छोड़ देना।
  • Resource utilisation के बिना response times report करना, जिससे report "slow" तो कहती है पर यह नहीं कि limit कहाँ है।
  • Wi-Fi पर laptop से, या saturated load generator से मापना, और network या tool के जोड़े समय का दोष server पर डालना।

QA का नज़रिया

पहले run से पहले metric definitions तय करें: कौन-से transactions मापे जाएँगे, घड़ी कहाँ शुरू और कहाँ बंद होगी, error क्या गिना जाएगा, कौन-से percentiles और time window report होंगे, और non-functional requirements से targets। Developers या operations से server dashboards का access माँगें, ताकि resource utilisation load की उसी timeline पर दर्ज हो। Load सिर्फ़ उन्हीं systems पर generate करें जो आपके हैं या जिन्हें test करने की लिखित अनुमति आपके पास है।

Report में हर number को उसका context दें: load level, duration, environment, tool, और measurement client side का है या server side का। Raw results सँभालकर रखें ताकि अगला run बराबरी से compare हो सके। जब कोई target miss हो, तो metric, miss का आकार और उस पल saturated resource का नाम बताएँ।

अभ्यास

Search API run के metrics निकालें और परखें

आपका काम

Staging में GET /api/search पर पाँच मिनट के steady-state run ने नीचे का summary दिया। Requirement कहती है: "Search कम से कम 40 requests per second संभालता है, 1% से कम error rate और 300 ms से कम median response time के साथ।"

Metrics निकालें, तय करें कि requirement पूरी हुई या नहीं, और वह finding लिखें जो आप report करेंगे और वह सवाल जो आप team से पूछेंगे।

सामग्री
GET /api/search · staging · 300 s steady state · 60 virtual users

Requests sent              13,500
HTTP 200                   13,257  (27 of them with body {"error":"index busy"})
HTTP 504                   135
Client timeouts (3 s)      108
Median response time       180 ms  (all responses, errors included)
App server CPU             92% average, 98% peak
Database CPU               35% average
Load generator CPU         40% average
चरण
  1. Successful requests गिनें और उनका throughput निकालें।
  2. हर तरह की failure गिनें और error rate निकालें।
  3. Target से तुलना करने से पहले जाँचें कि median response time किन requests को cover करता है।
  4. Resource figures से limit की जगह पहचानें।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Throughput: 13,257 − 27 = 13,230 successful requests; 13,230 / 300 = 44.1 per second। 40 per second का target पूरा है।

Error rate: 135 HTTP 504 responses, 108 timeouts और error body वाले 27 status 200 responses मिलाकर 270 failed requests; 270 / 13,500 = 2.0%, 1% limit का दोगुना। Requirement पूरी नहीं हुई। सिर्फ़ 504 गिनने पर ठीक 1.0% आता है, जो फिर भी "1% से कम" में fail है, लेकिन आधी failed requests छिपा देता है।

Median: 180 ms, 300 ms से कम है, लेकिन इसमें failed और successful requests मिली हुई हैं। इस target को पूरा मानने से पहले सिर्फ़ successful requests का median माँगें।

Limit: application server CPU का average 92% और peak 98% है, जबकि database (35%) के पास headroom है और load generator (40%) bottleneck नहीं है। Report: "44 requests per second पर error rate 2.0%, limit 1%; app server CPU 92–98%।" पूछें कि क्या staging के application server को production जितना CPU मिला है, और search service हर request पर क्या करती है।

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

क्या latency और response time एक ही हैं?

ज़रूरी नहीं। Response time request भेजने से पूरा response मिलने तक का पूरा समय है। Latency का मतलब network पर data के सफ़र का समय, पहले byte तक का समय, या कुछ monitoring vocabularies में पूरा response time हो सकता है। अपने tool की definition जाँचें और बताएँ कि हर number किस अर्थ में है।

अच्छा response time कितना होता है?

कोई universal number नहीं है। Target हर transaction के लिए non-functional requirements या किसी SLO से आता है, जैसे तय load पर तय समय के नीचे कोई percentile। Target न हो तो पिछले release के baseline से तुलना करें।

Throughput मेरे configure किए load से कम क्यों है?

क्योंकि throughput वह काम गिनता है जो system ने पूरा किया। Responses धीमे हों तो अपने response का इंतज़ार करने वाला हर virtual user कम requests भेजता है; timeout होने वाली requests कभी पूरी नहीं होतीं, और successful throughput मापते समय failed requests नहीं गिनी जातीं। Configure किए load और throughput के बीच का अंतर अपने आप में एक finding है।

संदर्भ

  • Certified Tester Performance Testing (CT-PT)ISTQB · 2018performance testing पर ISTQB का specialist पाठ्यक्रम: बुनियादी अवधारणाएँ, performance measurements, टेस्ट गतिविधियाँ व कार्य, और टूल।
  • Monitoring Distributed Systems — Site Reliability Engineering (Rob Ewaschuk)Google / O'Reilly Media · 2016monitoring पर Google की SRE गाइडेंस: black-box बनाम white-box monitoring और चार golden signals — latency, traffic, errors और saturation।
  • Grafana k6 documentationGrafana LabsGrafana k6 का आधिकारिक दस्तावेज़ — एक open-source और extensible load व performance testing टूल।
  • Apache JMeter User's ManualApache Software FoundationJMeter से लोड टेस्ट कैसे बनाएँ, पैरामीटराइज़ करें और चलाएँ, और उसके लिसनर व रिपोर्ट कैसे पढ़ें।
टूल्स

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

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

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

परफ़ॉर्मेंस

रिस्पॉन्स साइज़ एनालाइज़र

रिस्पॉन्स साइज़ का विश्लेषण: कच्चे बनाम compressed बाइट, हेडर का साइज़, JSON ढाँचे का भार और सबसे बड़े फ़ील्ड।

परफ़ॉर्मेंस

API परफ़ॉर्मेंस कंपेरेटर

दो endpoint के रिस्पॉन्स टाइम और साइज़ की आमने-सामने तुलना करें (जैसे v1 बनाम v2, staging बनाम production)।

परफ़ॉर्मेंस

और गहराई से

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

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