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

कॉन्करेंट यूज़र्स और वर्कलोड मॉडल

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

Performance requirements अक्सर load को लोगों में बताती हैं, जैसे "portal को 2,000 concurrent users सपोर्ट करने चाहिए", जबकि servers और load tools rates में काम करते हैं। Concurrent users वे लोग हैं जिनका एक ही अवधि में active session (यानी पहले page से जाने तक की एक visit) है; उनमें से ज़्यादातर पढ़ रहे, टाइप कर रहे या सोच रहे होते हैं, server का इंतज़ार नहीं कर रहे। Requests per second (RPS) बताता है कि हर सेकंड कितनी requests आती हैं, या पूरी होती हैं। Workload model इन दोनों को जोड़ता है: users कौन-सी journeys करते हैं और किस mix में, कितनी तेज़ी से आते हैं, steps के बीच कितना रुकते हैं (think time) और हर simulated user अपनी journey कितनी बार दोहराता है (pacing)।

उदाहरण के लिए, किसी online store के शाम के peak पर 1,350 shoppers सिर्फ़ 90 requests per second भेज सकते हैं। Little’s law ऐसे numbers को जोड़ता है और जल्दी दिखा देता है कि test ने वही load लगाया या नहीं जिसका वह दावा करता है।

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

Load test उतना ही meaningful है जितना उसका लगाया load। 1,350 virtual users को बिना रुके चलाएँ तो वे 90 की जगह हज़ारों requests per second भेजेंगे, और system ऐसे test में fail हो सकता है जिसका असलियत से कोई लेना-देना नहीं। सही संख्या के users को सिर्फ़ home page पर चलाएँ तो cache सब कुछ जवाब दे देगा, जबकि checkout, जो orders लिखता है और payment provider को call करता है, पर कोई load नहीं पड़ेगा।

Tester के लिए यह model requirements को चुनौती देने और results पढ़ने का तरीका है: "2,000 users सपोर्ट करें" तब तक टेस्ट नहीं हो सकता जब तक कोई न बताए कि कौन-से users, क्या करते हुए, किस rate पर।

Concurrent users, requests in flight और requests per second

तीन numbers अक्सर गड़बड़ा जाते हैं। Concurrent users का एक ही अवधि में active session होता है, चाहे वे अभी response का इंतज़ार कर रहे हों या नहीं। Requests in flight, जिन्हें कभी-कभी concurrent requests कहा जाता है, वे हैं जिन्हें server किसी एक पल में process कर रहा है। Requests per second आने वाली या पूरी होने वाली requests की rate है; पूरी होने की rate throughput है, जो system के load संभालते रहने तक arrival rate के बराबर रहती है।

Load tools एक चौथा term जोड़ते हैं: virtual user (VU), यानी test script की एक चलती हुई copy जो एक user की भूमिका निभाती है। जो VU इंसान की तरह रुकता है वह एक concurrent user जैसा है; जो कभी नहीं रुकता वह कई लोगों जितना traffic बनाता है। कुछ teams "concurrent users" कहकर requests in flight का मतलब लेती हैं, इसलिए पूछें कि requirement का मतलब कौन-सा है।

Workload model में क्या होता है

Workload model उस load का वर्णन है जो test को लगाना चाहिए ताकि वह production जैसा हो। ISTQB Performance Testing syllabus users के काम के pattern को operational profile कहता है; फिर load profile बताता है कि एक तय समय-अवधि में कितने virtual users कौन-से operational profiles चलाते हैं, जैसे ramp-up के बाद steady state। Model को evidence से बनाएँ: analytics, access logs, monitoring data या business forecast।

यह भी तय करें कि load कैसे generate होगा। Closed model में तय संख्या के virtual users अपनी journeys में loop करते हैं और हर एक अगली request पिछली पूरी होने के बाद ही भेजता है, इसलिए धीमे होते system को कम requests मिलती हैं और test अपने-आप load घटा देता है। Open model में users एक तय rate पर आते हैं, response time चाहे जो हो, इसलिए धीमे होते system में काम जमा होता जाता है। k6 में constant-vus closed है और constant-arrival-rate open। Public sites और APIs के लिए open model और 200 call-centre agents जैसी तय आबादी के लिए closed model इस्तेमाल करें।

  • Journeys: ज़रूरी user journeys, जैसे search और checkout, हर एक requests का sequence।
  • Mix: sessions में हर journey का हिस्सा, जैसे 50% browsing और 15% checkout।
  • Rate: टेस्ट की जाने वाली अवधि में, आम तौर पर peak hour में, हर सेकंड शुरू होने वाले sessions।
  • Data: इतने अलग-अलग users, products और search terms कि cache production की तरह व्यवहार करे।

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

Think time और pacing

Think time वह ठहराव है जो असली user journey के दो steps के बीच लेता है: page पढ़ना, address टाइप करना। यह script में requests के बीच होता है। इसे analytics (time on page) से लें और random रखें, जैसे fixed 19.5 s की जगह 15 से 24 s, ताकि virtual users एक साथ क़दम न मिलाएँ और server पर लहरों में न आएँ। JMeter इसे Uniform Random Timer जैसे timers से जोड़ता है, k6 sleep() से।

Pacing एक ही virtual user के लिए एक iteration (एक पूरी journey) की शुरुआत से अगली की शुरुआत तक का अंतराल है। 300 s की pacing और 240 s की journey में VU 60 s इंतज़ार करता है, यानी हर पाँच मिनट में एक checkout शुरू करता है। अगर system धीमा हो और journey 300 s से ज़्यादा ले, तो planned rate छूट जाती है, जो अपने-आप में एक finding है।

One virtual user, checkout journey: 12 requests, pacing 300 s
Each step: ~0.5 s response + think time, random 15-24 s (mean 19.5 s)

   time  what the virtual user does
    0 s  request 1: view cart, then think
   20 s  request 2: enter address, then think
    ...  requests 3 to 11, about 20 s apart
  220 s  request 12: confirm payment, then think
  240 s  journey done, wait 60 s for the next pacing slot
  300 s  iteration 2 starts: request 1: view cart

Think time = pause between requests inside one journey
Pacing     = start of one journey to start of the next

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

Little’s law: users, rates और समय

Little’s law कहता है कि किसी stable system में अंदर मौजूद items की average संख्या, average arrival rate गुणा हर item के अंदर बिताए average समय के बराबर होती है: L = λ × W। यह दुकान के counter की line, server या पूरी website, सब पर लागू होता है, arrivals का pattern चाहे जो हो। Units एक जैसी रखें: requests per second के साथ seconds।

तीन स्तरों पर लगाने से यह इस lesson के सवालों का जवाब देता है, और उल्टा पढ़ने पर report की जाँच करता है:

  • Server: requests in flight = RPS × average response time: 90 × 0.5 s = 45।
  • Users: concurrent users = हर सेकंड शुरू होने वाले sessions × average session duration; नीचे के worked example वाले store के लिए 10 × 135 s = 1,350।
  • Script: virtual users = target RPS × (हर request का response time + think time): 90 × 15 s = 1,350 VUs; think time के बिना 90 × 0.5 s = 45 VUs वही 90 RPS भेज देते हैं। ISTQB Performance Testing syllabus इसे throughput = virtual users / (processing time + think time) के रूप में लिखता है।
  • Report check: 0.4 s responses और 5 s think time वाले 200 VUs लगभग 200 / 5.4 ≈ 37 RPS बनाते हैं। अगर report 150 RPS दिखाए, तो हर VU ने हर request पर सिर्फ़ लगभग 200 / 150 ≈ 1.3 s लगाए, यानी planned think time का ज़्यादातर हिस्सा लागू ही नहीं हुआ।
  • Limits: steady अवधि के averages इस्तेमाल करें, p95 या अभी बढ़ रही queue नहीं।

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

Worked example: analytics से workload model तक

एक online store sale की शाम की तैयारी कर रहा है। पिछले साल के सबसे busy घंटे में 36,000 sessions थे, यानी हर सेकंड 10, जो चार journeys में बँटे थे। हर journey के लिए analytics sessions में उसका हिस्सा, requests per session और हर step का average समय (response और think time मिलाकर) देते हैं।

किसी journey का RPS = sessions per second × हिस्सा × requests per session; उसके concurrent users = उसका RPS × हर step का समय, यही Little’s law है। कुल: 90 RPS और 1,350 concurrent users। Checkout sessions का 15% है लेकिन requests का 20%, क्योंकि checkout session में सबसे ज़्यादा requests होती हैं, और users का 27%, क्योंकि लोग checkout के हर step पर सबसे ज़्यादा समय लगाते हैं; mix के बिना test ठीक उन्हीं sessions और payment calls पर कम load डालेगा जो सबसे अहम हैं।

Online store का peak hour: चार journeys पर हर सेकंड 10 नए sessions से 90 requests per second बनती हैं लेकिन 1,350 concurrent users, क्योंकि हर journey के users = उसकी requests per second × हर step का समय।
JourneySessions में हिस्साRequests प्रति sessionहर step का समयresponse + think timeRequests per secondsessions/s × हिस्सा × requestsConcurrent usersrequests/s × हर step का समय
Catalogue browse करना50%815 s4010 × 0.50 × 860040 × 15
Search और compare30%1012 s3010 × 0.30 × 1036030 × 12
Checkout15%1220 s1810 × 0.15 × 1236018 × 20
Order track करना5%415 s210 × 0.05 × 4302 × 15
कुल100%औसतन 9औसतन 15 s9010 × 91,35090 × 15
  • Checkout: 15% sessions और 20% requests, लेकिन 27% concurrent users

Peak hour: 36,000 sessions = हर सेकंड 10 नए sessions। 0.5 s के average response पर किसी भी पल server पर सिर्फ़ 90 × 0.5 = 45 requests process हो रही होती हैं।

पाठ संस्करण
Peak hour: 36,000 sessions / 3,600 s = 10 new sessions per second

journey           share  requests  s/step  requests per second  concurrent users
browse catalogue   50%       8       15    10 × 0.50 × 8  = 40    40 × 15 =   600
search, compare    30%      10       12    10 × 0.30 × 10 = 30    30 × 12 =   360
checkout           15%      12       20    10 × 0.15 × 12 = 18    18 × 20 =   360
track an order      5%       4       15    10 × 0.05 × 4  =  2     2 × 15 =    30
total             100%   9 avg   15 avg                   = 90              1,350

requests = requests per session; s/step = response + think time per request
avg = weighted: 90 / 10 = 9 requests per session; 1,350 / 90 = 15 s per request
average session duration = 9 × 15 = 135 s; 10 sessions/s × 135 s = 1,350 users
In flight on the server at 0.5 s average response: 90 × 0.5 = 45 requests

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

आम गलतियाँ

  • "Concurrent users" वाले number को बिना think time के virtual users के रूप में चलाना, जिससे request rate कई गुना हो जाती है।
  • Registered या daily users को concurrent users मान लेना। Peak अवधि का number और उसका source माँगें।
  • Mix की जगह एक ही journey टेस्ट करना, अक्सर home page; cached pages checkout की धीमी writes छिपा देते हैं।
  • हर virtual user को एक ही fixed think time देना, जिससे server को steady traffic की जगह लहरें दिखती हैं।
  • Closed model में गिरती request rate को सफलता समझना: धीमे system को बस कम requests मिलती हैं।
  • Little’s law में p95 या एक धीमा मिनट डालना, जबकि इसे steady अवधि के averages चाहिए।

QA का नज़रिया

किसी के script लिखने से पहले workload model बनाएँ और उसे किसी भी test basis की तरह review करवाएँ: product owner volumes और peak events देता है (salary day, sale), analytics sessions per hour और time on page देते हैं, और developers बताते हैं कि हर journey कौन-सी requests भेजती है। जब requirement कहे "2,000 concurrent users", तो पूछें: sessions या requests in flight, किस अवधि में, कौन-सी journeys करते हुए?

Test plan में दर्ज करें कि हर number कहाँ से और किन तारीख़ों का है। हर run के बाद response times देखने से पहले achieved rate और mix को model से मिलाएँ, और report को Little’s law से जाँचें। जिस run ने intended load नहीं लगाया वह invalid है, pass या fail नहीं।

अभ्यास

Appointment portal का workload model बनाएँ

आपका काम

एक सरकारी appointment portal नई booking window खुलने पर सबसे busy होता है: peak hour में 18,000 sessions, नीचे की तीन journeys में बँटे, और expected average response time 0.4 s। हर journey और कुल के लिए RPS और concurrent users निकालें, और requests in flight भी।

एक साथी बिना think time के 1,000 virtual users का सुझाव देता है। Little’s law से दिखाएँ कि इससे असल में कितना load लगता है।

सामग्री
Peak hour: 18,000 sessions

journey               share   requests per session   time per step (response + think)
search free slots      60%             6                        10 s
book an appointment    30%            10                        18 s
cancel or reschedule   10%             4                        15 s
चरण
  1. Peak hour को sessions per second में बदलें।
  2. हर journey के लिए sessions per second, RPS और session duration निकालें।
  3. Little’s law से concurrent users और requests in flight निकालें।
  4. Booking journey के लिए pacing चुनें और closed-model script के लिए ज़रूरी virtual users निकालें।
  5. साथी की plan की request rate निकालें।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Sessions per second: 18,000 / 3,600 = 5, यानी search के लिए 3, booking के लिए 1.5 और cancel के लिए 0.5।

Search: 3 × 6 = 18 RPS; session 6 × 10 = 60 s, इसलिए 3 × 60 = 180 users। Booking: 1.5 × 10 = 15 RPS; session 10 × 18 = 180 s; 1.5 × 180 = 270 users। Cancel: 0.5 × 4 = 2 RPS; session 60 s; 30 users।

कुल: 35 RPS और 480 concurrent users; requests in flight 35 × 0.4 = 14। Booking sessions का 30% है लेकिन users का 56%, इसलिए सबसे ज़्यादा ध्यान और test data उसी को चाहिए।

Booking लगभग 180 s लेती है, इसलिए गुंजाइश वाली pacing लें, जैसे 200 s: VUs = 1.5 × 200 = 300, जिनमें से लगभग 270 किसी भी पल journey के बीच होते हैं। Journeys 200 s से ज़्यादा लें तो rate 1.5 per second से नीचे गिरेगी: यह एक finding है।

Think time के बिना साथी का हर user पिछला response आते ही अगली request भेज देता है, यानी हर 0.4 s में: जब तक responses 0.4 s पर रहें, 1,000 / 0.4 = 2,500 RPS, model के 35 का लगभग 70 गुना। यह बाद में उपयोगी stress test हो सकता है, लेकिन expected load नहीं है।

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

100 requests per second के लिए कितने virtual users चाहिए?

यह इस पर निर्भर है कि हर user हर request पर कितना समय लगाता है। Little’s law से: virtual users = requests per second × (average response time + average think time)। 0.5 s responses और 9.5 s think time के साथ यह 100 × 10 = 1,000 users है; think time के बिना 100 × 0.5 = 50। पहले तय करें कि आप लोगों को simulate कर रहे हैं (think time रखें) या सिर्फ़ request rate (open model, जिसमें tool rate सीधे तय करता है)।

क्या load-generator machines बचाने के लिए think time हटा दूँ?

सिर्फ़ तब जब server में टेस्ट करने लायक per-user state न हो, जैसे fixed rate पर मापा गया stateless API। कम और तेज़ users असली आबादी से कम sessions और connections खोलते हैं और कम memory लेते हैं, इसलिए users की संख्या के साथ बढ़ने वाली समस्याएँ, जैसे session storage या connection pools, छिपी रह जाती हैं। Think time हटाएँ तो plan और report में यह लिखें।

Open workload model इस्तेमाल करूँ या closed?

Open model तब इस्तेमाल करें जब users एक-दूसरे से और system की speed से स्वतंत्र आते हैं, जैसे public website या API पर। Closed model तब इस्तेमाल करें जब एक तय group system इस्तेमाल करता है, जैसे 200 call-centre agents या batch workers का pool, क्योंकि उनकी अगली request सचमुच पिछले response का इंतज़ार करती है।

क्या Little’s law exact है?

Stable system में long-run averages के लिए हाँ, arrivals और durations का distribution चाहे जो हो। यह ramp-up या overload के दौरान की छोटी window का वर्णन नहीं करता, जब अंदर की संख्या अभी बदल रही हो, और percentiles के बारे में कुछ नहीं कहता: इसे test का size तय करने और sanity check के लिए इस्तेमाल करें, p95 का अनुमान लगाने के लिए नहीं।

संदर्भ

  • Certified Tester Performance Testing (CT-PT)ISTQB · 2018performance testing पर ISTQB का specialist पाठ्यक्रम: बुनियादी अवधारणाएँ, performance measurements, टेस्ट गतिविधियाँ व कार्य, और टूल।
  • ISTQB GlossaryISTQBटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
  • 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 पाएँ।

परफ़ॉर्मेंस

और गहराई से

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

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

इस topic से पहले