परफ़ॉर्मेंस रिज़ल्ट्स का विश्लेषण

Mutqan Soft QA टीम द्वारा · अपडेट 6 अक्टूबर 2026 · 21 मिनट · मध्यम

Performance results का विश्लेषण वह कदम है जो एक पूरे हो चुके load, stress, spike, soak या capacity run और एक फ़ैसले के बीच आता है। Load tool system को बाहर से दिखाता है: समय के साथ response time percentiles, throughput और error rate। Monitoring उसे अंदर से दिखाती है: उसी timeline पर CPU, memory, database और network का उपयोग। विश्लेषण दोनों को जोड़कर तीन सवालों का जवाब देता है: क्या objectives पूरे हुए, किस resource ने system को सबसे पहले सीमित किया, और अगले run से पहले क्या बदलना चाहिए।

उदाहरण के लिए, एक checkout API ने 40 requests per second पर अपने targets पूरे किए और 60 पर fail हुई। Summary table बस "slow" कहती है। Timeline दिखाती है कि p95 अपने target के अंदर रहते हुए भी error target चूक गया, database connection pool 10 में से 10 पर था जबकि database CPU 48% पर बैठा था, और log में कोई slow query नहीं थी। यह धीमा database नहीं है, बल्कि बहुत छोटा या बहुत देर तक रोका गया pool है, और fix अलग है।

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

एक run हज़ारों numbers देता है, और उनसे एक फ़ैसला निकलना होता है: launch करें या रुकें, बड़ा database खरीदें या application servers जोड़ें, query ठीक करें या pool size बदलें। गलत number पढ़ें तो team हफ़्तों उस tier को scale करती रहती है जो कभी limit थी ही नहीं, जैसा पिछले lesson के plateau ने दिखाया। सही number पढ़ें तो configuration की एक line का बदलाव capacity दुगनी कर सकता है।

Tester के लिए विश्लेषण ही performance test को chart से finding बनाता है। "System 60 requests per second पर slow है" किसी को assign नहीं किया जा सकता। "60 requests per second से database connection pool saturate हो जाता है जबकि database CPU 50% से नीचे रहता है; requests connection के लिए queue में लगती हैं और 0.6% fail होती हैं" को assign, fix और re-test किया जा सकता है।

पहले run जाँचें, फिर curves को एक साथ पढ़ें

सबसे पहले जाँचें कि run व्याख्या के लायक है भी या नहीं। क्या tool planned load तक पहुँचा और उसका अपना CPU और network limits से काफ़ी नीचे रहे? क्या ramp-up और ramp-down numbers से बाहर रखे गए? क्या timeouts और connection errors को, जैसा तय था, errors में गिना गया? क्या build, environment और data volume plan से मेल खाते थे? जो दूसरा run पहले को reproduce न करे वह noise है: code पर फ़ैसला देने से पहले environment ठीक करें।

फिर summary table नहीं, समय के साथ curves पढ़ें। k6 और JMeter जैसे load tools हर request का result timestamp के साथ लिख सकते हैं, सिर्फ़ run के अंत का summary नहीं; उसी output का इस्तेमाल करें। Throughput, p50, p95 और p99, error rate और मुख्य resources को एक ही time axis पर रखें और चार signatures खोजें।

Response time बढ़े जबकि throughput सपाट हो जाए: curve का knee। कोई resource saturate हो गया है और requests उसके लिए queue में हैं। Knee बताता है कि यह workload अधिकतम कितना निकल सकता है; capacity, जैसा पिछले lesson में था, knee पर या उससे पहले का वह आख़िरी step है जिस पर हर objective अब भी पूरा होता है।
Errors response time से पहले बढ़ें: hard limit, slowness नहीं। कोई fixed size की चीज़ (connection pool, thread pool, connection या rate limit, queue) extra requests को HTTP 503, 429 या timeout से reject कर रही है, जबकि CPU अपनी ceiling से काफ़ी नीचे रहते हैं।
p99 p95 से बहुत ऊपर: ज़्यादातर requests ठीक हैं और कुछ किसी धीमी चीज़ से टकराती हैं, जैसे garbage-collection pauses, lock contention, cache-miss path या धीमी downstream call।
स्थिर load पर धीमी गिरावट: memory, connections, file handles या disk का leak या exhaustion, जैसा soak testing lesson में था।

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

Bottleneck खोजें: CPU, memory, database, network

Bottleneck वह resource है जो curve के मुड़ने के क्षण सबसे पहले saturate होता है; उसके बाद का सब कुछ उसका नतीजा है। जब database connection pool भर जाता है, तो application threads इंतज़ार करते हैं, requests load balancer पर queue में लगती हैं और client को timeouts दिखते हैं। एक तय क्रम में diagnose करें, सबसे सस्ती जाँच पहले, और knee पर saturate हुए पहले resource पर रुक जाएँ। फिर जाँचें कि वह cause है, consequence नहीं: garbage collection में busy CPU memory की ओर इशारा करता है, और retries में busy CPU उस failure की ओर जो उन retries की वजह है।

Hard limits: CPU अपनी ceiling से काफ़ी नीचे होते हुए errors। वह pool, thread count, connection limit, queue या rate limit खोजें जो 100% use में है। Fix कोई setting या design change है, जैसे connections जल्दी release करना, hardware नहीं।
CPU: knee पर application या database का CPU लगातार अपनी ceiling के पास (पिछले lesson में saturated tiers लगभग 90% या उससे ऊपर चल रहे थे)। Application CPU profiling और scale-out से सुधरता है; database CPU का मतलब आम तौर पर महँगी या बहुत ज़्यादा queries है, और application servers जोड़ने से मदद नहीं मिलती, उल्टे हालत और बिगड़ सकती है।
Memory: ऐसा heap जो बढ़ता है और कभी घटता नहीं, garbage collection का बढ़ता हिस्सा, swapping, या out-of-memory kill के बाद restarts। GC pauses p99 spikes के रूप में दिखते हैं, swapping सब कुछ एक साथ धीमा करती है, और restarts connection errors के bursts और शून्य तक गिरती memory के रूप में दिखते हैं।
Database और dependency waits: application threads idle पर requests slow, slow-query log entries, lock waits, I/O wait, या सेकंडों में जवाब देती third-party API। एक slow request का trace दिखाता है कि कौन-सी call समय रोके हुए है।
Network और payload: link capacity के पास bytes per second, बड़े या uncompressed responses, हर page पर बहुत सारे round trips, या retransmits। 100 requests per second पर 2 MB के responses को 1.6 Gbit/s चाहिए, जो 1 Gbit/s link की क्षमता से ज़्यादा है, server चाहे जितना तेज़ हो; server को दोष देने से पहले size जाँचें।
कुछ भी saturated नहीं: किसी एक lock या queue पर शक करें जो काम को serialise कर रहा है, कोई limit जिसे आपने graph नहीं किया, या unrealistic target। अंदाज़ा लगाने की बजाय missing layer के लिए monitoring जोड़ें और re-run करें।

छह सवाल क्रम से चूके हुए target के पीछे का bottleneck खोजते हैं: पहले load generator, फिर hard limits, फिर CPU, memory, database या dependency waits और network।

क्या load generator planned load तक पहुँचा और उसका अपना CPU और network limits से काफ़ी नीचे रहे?

उत्तर: नहीं
परिणाम: Tool limit: results generator के बारे में बताते हैंGenerator ठीक करें या बढ़ाएँ, फिर re-run करें।
उत्तर: हाँ
प्रश्न 2: क्या errors (503, 429, timeouts) बढ़ते हैं जबकि हर CPU अपनी ceiling से काफ़ी नीचे रहता है?
- उत्तर: हाँ
  परिणाम: Hard limitConnection pool, thread pool, connection limit, queue या rate limit 100% use में। Setting या design change, hardware नहीं।
- उत्तर: नहीं
  प्रश्न 3: क्या knee पर कोई CPU लगातार अपनी ceiling के पास है?
  - उत्तर: हाँ, application tier
    परिणाम: Application CPUपहले garbage-collection time को rule out करें, फिर hot code profile करें या scale out करें।
  - उत्तर: हाँ, database server
    परिणाम: Database CPUमहँगी या बहुत ज़्यादा queries; application servers जोड़ने से मदद नहीं मिलती, हालत बिगड़ भी सकती है।
  - उत्तर: नहीं
    प्रश्न 4: क्या memory बढ़ रही है, garbage collector busy है, या server swap कर रहा है?
    उत्तर: हाँ
    परिणाम: MemoryLeak या छोटा heap। GC pauses p95 से बहुत ऊपर p99 के रूप में दिखते हैं; swapping सब कुछ एक साथ धीमा करती है।
    उत्तर: नहीं
    प्रश्न 5: क्या समय database या किसी downstream service के इंतज़ार में जा रहा है?
    उत्तर: हाँ
    परिणाम: Database या dependency waitsSlow queries, lock contention, I/O wait या धीमी third-party API; trace बताता है कौन-सी।
    उत्तर: नहीं
    प्रश्न 6: क्या network link या payload ही limit है?
    उत्तर: हाँ
    परिणाम: Network और payloadCeiling के पास bandwidth, बड़े या uncompressed responses, बहुत सारे round trips या retransmits।
    उत्तर: नहीं
    परिणाम: कोई saturated resource नहींकिसी एक lock या queue, न graph की गई limit, या unrealistic target पर शक करें; monitoring जोड़ें और re-run करें।

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

Run को monitoring से correlate करें

Load tool black-box monitoring है: यह बाहर से symptoms देखता है। Server monitoring white-box है: यह अंदर से causes देखती है। Google SRE book के चार golden signals, latency, traffic, errors और saturation, बताते हैं कि क्या मिलाना है: पहले तीन tool देता है, saturation servers देते हैं, और correlation तभी काम करता है जब दोनों एक timeline साझा करें।

एक timeline: clocks और time zones sync करें, start, end और हर load step का clock time लिखें, और steps को dashboards पर mark करें। उदाहरण के लिए, JMeter के CSV results हर sample का समय 1 जनवरी 1970 (UTC) से milliseconds में देते हैं; उसे dashboard के time zone में convert करें। सिर्फ़ steady-state windows की तुलना करें, कभी ऐसी window की नहीं जिसमें ramp-up शामिल हो।
Request के क्रम में layers पर चलें: load balancer (active connections, 5xx), application (हर endpoint की requests और latency, thread और connection pools, GC, heap), database (connections, slow queries, lock waits, CPU, I/O), infrastructure (CPU, memory, disk, network bytes), फिर अकेली slow requests के लिए logs और traces।
जो metric curve के मुड़ते ही हिलता है वह hypothesis है, proof नहीं। एक चीज़ बदलें (pool बढ़ाएँ, index जोड़ें, scale out करें), re-run करें और देखें कि knee हिला या नहीं। नहीं हिला तो bottleneck कहीं और है; हिला तो अगला अब दिखने लगा है।

आज़माएँ: टाइमस्टैम्प कन्वर्टर

Worked example: एक checkout run जो target से चूक गया

एक online store ने staging में POST /api/checkout पर stepped load test चलाया, हर step दस मिनट, target: 60 requests per second पर p95 800 ms से कम और errors 0.5% से कम। Load generator 30% CPU से नीचे रहा। Table हर step की steady state के लिए tool के results को dashboards से जोड़ती है; Offered वह arrival rate है जो tool ने लगाया, और Completed throughput है।

Step 3 error target (0.6%) से चूकता है हालाँकि p95 बस-बस pass होता है, और 2,100 ms का p99 एक tail दिखाता है। Curve यहीं मुड़ता है: step 4 20 req/s ज़्यादा offer करता है पर सिर्फ़ 3 req/s ज़्यादा complete करता है।
दोनों में कोई CPU saturated नहीं (application 64%, database 48%), पर database connection pool step 3 से 10 में से 10 पर है और errors 503 और timeouts हैं: hard limit। Slow-query log में 100 ms से ऊपर कुछ नहीं, यानी database slow नहीं है; connections कम हैं। एक checkout के trace से दिखता है कि payment-provider call (low load पर checkout के 180 ms में से लगभग 120 ms) के दौरान transaction खुला रहता है, इसलिए हर request अपनी ज़्यादातर उम्र एक connection रोके रखती है। Little’s law इसकी पुष्टि करता है: हर एक लगभग 0.15 s तक रोके गए 10 connections अधिकतम लगभग 65 requests per second serve कर सकते हैं (10 ÷ 0.15), जो step 4 के 61 completed के क़रीब है।
Finding: 60 req/s से checkout service का database connection pool (10) saturate हो जाता है जबकि database CPU 50% से नीचे रहता है; requests connection के लिए queue में लगती हैं और 0.6% 503 या timeout से fail होती हैं। Suspected cause: connection payment-provider call के दौरान रोका जाता है। अगला experiment: external call से पहले connection release करें, या database की connection limit अनुमति दे तो pool 20 करें, फिर steps 3 और 4 re-run करें।

POST /api/checkout · staging · build 4.12.0 · 10 min per step · steady state only
Target at 60 req/s: p95 < 800 ms, errors < 0.5 %

Step  Offered  Completed   p50     p95     p99   Errors  App CPU  DB CPU  DB pool   Heap
      req/s    req/s        ms      ms      ms
  1     20       20        180     310     420   0.0 %    28 %     22 %     3/10   1.1 GB
  2     40       40        190     350     520   0.0 %    51 %     41 %     6/10   1.2 GB
  3     60       58        240     790   2,100   0.6 %    64 %     48 %    10/10   1.2 GB
  4     80       61        610   3,400   5,000   7.8 %    66 %     49 %    10/10   1.2 GB

5,000 ms = client timeout. Errors: HTTP 503 and timeouts. Slow-query log: none > 100 ms.

ऐसी finding report करें जिस पर कोई काम कर सके

Performance report तीन audiences के तीन सवालों का जवाब देती है: क्या objectives पूरे हुए (product owner, release manager), system को क्या और क्यों सीमित करता है (developers, operations), और अगले run से पहले क्या बदलना चाहिए (सब)। ISTQB Performance Testing syllabus results के विश्लेषण और reporting को execution के बाद का एक अलग task मानता है। पहले verdict लिखें, उसके बाद evidence, और raw results सँभाल कर रखें ताकि अगला run like for like compare हो।

हर objective का verdict: target, measured value, pass या fail, और किस load पर: "p95 790 ms (target 800) pass; errors 0.6% (target 0.5%) fail, 60 req/s पर"।
ऐसा context जो numbers को comparable बनाए: build, environment और वह production से कैसे अलग है, data volume, workload model, load profile, dates, tool और उसका version, और error क्या गिना गया।
Findings defect reports की तरह लिखी हुई: सटीक numbers के साथ observed बनाम expected, saturated resource और उसका correlated evidence, दो runs में reproducibility, forecast load पर impact, और severity। हर bottleneck की एक finding।
Recommendations experiments के रूप में: क्या बदलना है, कौन-सा metric हिलना चाहिए, और कौन-सा re-run इसकी पुष्टि करेगा। Test की limits भी जोड़ें, ताकि कोई staging के number को production का वादा न समझे।
एक विश्लेषण से दो formats: users क्या अनुभव करेंगे इसका सादे शब्दों में छोटा summary, और engineers के लिए tables और annotated graphs।

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

आम गलतियाँ

सिर्फ़ summary table पढ़ना। Averages और totals knee, tail और errors शुरू होने का क्षण छिपा देते हैं।
पहले busy resource को दोष देना। 100% पर CPU retries या garbage collection का नतीजा हो सकता है; bottleneck वह है जो knee पर सबसे पहले saturate हुआ।
Client की timeline को दूसरे time zone के dashboard से, या steady-state window को ramp-up वाली window से compare करना।
Correlation को proof मानना और उस re-run के बिना fix recommend करना जो उसकी पुष्टि करता।
Load level, objective, saturated resource और numbers के बिना "system slow है" report करना।
दो runs के बीच कई चीज़ें बदल देना, जिससे किसी को पता न चले कि किस बदलाव ने knee हिलाया।

QA का नज़रिया

असली team में tester के पास dashboards की ownership कम ही होती है, इसलिए विश्लेषण run से पहले शुरू होता है: operations से monitoring का access माँगें, time zone तय करें, step times के साथ run plan लिखें और किसी developer से run के दौरान उपलब्ध रहने को कहें। बाद में layers का पहला pass किसी developer या operations engineer के साथ करें; जो pool size जानता है उसके साथ काम तेज़ चलता है। Load सिर्फ़ उन systems पर दें जो आपके हैं या जिनके test की लिखित अनुमति है।

हर run के लिए plan, raw results, steady-state windows की exported series या screenshots, findings और लिया गया फ़ैसला सँभाल कर रखें। अगला run इसी से compare होगा, और fix के बाद वही table सबूत है कि fix ने काम किया। जब किसी finding पर विवाद हो, correlated timeline उसे तय करती है।

अभ्यास

एक search API run का diagnosis करें और finding लिखें

आपका काम

Staging में GET /api/search पर एक stepped load test ने नीचे की table दी। Target: 150 requests per second पर p95 300 ms से कम और errors 1% से कम; load generator 25% CPU से नीचे रहा।

वह step खोजें जहाँ curve मुड़ता है, अपने evidence के साथ bottleneck का नाम लें, बताएँ कि monitoring में आगे क्या जाँचेंगे, और finding वैसे लिखें जैसे report करेंगे।

सामग्री

GET /api/search · staging · build 2.8.1 · 10 min per step · steady state only
Target at 150 req/s: p95 < 300 ms, errors < 1 %

Step  Offered  Completed   p50     p95     p99   Errors  App CPU  DB CPU  DB pool   Heap
      req/s    req/s        ms      ms      ms
  1     50       50         80     140     210   0.0 %    35 %     30 %     3/50   0.9 GB
  2    100      100         95     190     290   0.0 %    62 %     57 %     7/50   1.0 GB
  3    150      149        160     420     900   0.1 %    71 %     96 %    23/50   1.0 GB
  4    200      152        480   1,900   3,600   2.4 %    70 %     98 %    49/50   1.0 GB

Errors: HTTP 503 and timeouts. Slow-query log at step 3: 52,000 entries over 100 ms,
all the same search query on the products table (full scan of 300,000 rows).

चरण

वह step खोजें जहाँ response time बढ़ता है जबकि completed throughput बढ़ना बंद कर देता है।
जाँचें कि उस step पर कौन-से resources अपनी ceiling के पास हैं, और कौन-से नहीं।
तय करें कि signature hard limit है, CPU, memory, database या network।
Numbers, evidence, suspected cause और अगले experiment के साथ finding लिखें।

मॉडल उत्तर दिखाएँ

मॉडल उत्तर

Knee step 3 पर है: p95 190 से 420 ms और p99 900 ms तक बढ़ता है, जबकि step 4 50 req/s ज़्यादा offer करता है और सिर्फ़ 3 req/s ज़्यादा complete करता है। p95 target 150 req/s पर चूकता है; errors (0.1%) वहाँ अभी target के अंदर हैं, इसलिए यह hard limit नहीं है।

Database CPU ठीक knee पर saturated है (96%, फिर 98%), जबकि application CPU (71%) नहीं है और heap सपाट है। Pool सिर्फ़ step 4 पर भरता है (50 में से 49) क्योंकि slow queries connections ज़्यादा देर रोकती हैं: यह नतीजा है, कारण नहीं। Slow-query log कारण दिखाता है: step 3 पर लगभग 89,000 searches (दस मिनट तक 149 req/s) में से 52,000 को 100 ms से ज़्यादा लगा, और सब वही query थी जो 300,000 rows वाली पूरी products table scan करती है। Monitoring में आगे: उसी window के लिए database I/O wait और cache hit ratio, और एक slow search का trace।

Finding: 150 req/s से search अपना p95 target चूकता है (420 ms, target 300) क्योंकि database CPU 96% पर saturate होता है; slow-query log दिखाता है कि search query पूरी products table (300,000 rows) scan करती है। Errors 150 req/s पर target के अंदर रहते हैं और सिर्फ़ 200 req/s पर उसे पार करते हैं (2.4%)। Suspected cause: search filter के लिए missing index। अगला experiment: staging में index जोड़ें, steps 2 से 4 re-run करें और जाँचें कि 150 req/s पर database CPU गिरता है और knee 200 req/s के आगे जाता है। Application instances जोड़ना मदद नहीं करेगा: application CPU 71% पर है।

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

पहले क्या पढ़ूँ: load tool के results या server dashboards?

पहले tool के results, यह जानने के लिए कि objectives चूके या नहीं और कब, और curve कहाँ मुड़ता है। फिर ठीक उसी window के dashboards, यह जानने के लिए कि कौन-सा resource saturate हुआ। Tool symptoms दिखाता है; monitoring causes दिखाती है।

क्या एक से ज़्यादा bottleneck हो सकते हैं?

हाँ, पर किसी दिए गए workload में आम तौर पर एक समय में सिर्फ़ एक throughput को सीमित करता है। पहले को हटाते ही throughput तब तक बढ़ता है जब तक अगला resource saturate न हो, जैसा capacity lesson के plateau ने दिखाया जब limit application tier से database पर चली गई। Knee पर active वाले को report करें और fix के बाद अगले की उम्मीद रखें।

क्या results analyse करने के लिए distributed tracing ज़रूरी है?

नहीं। एक timeline पर metrics और database का slow-query log अक्सर bottleneck ढूँढने के लिए काफ़ी होते हैं। Tracing तब मदद करती है जब metrics "waiting" कहें पर किस पर, यह न बताएँ: वह दिखाती है कि एक slow request का समय services के बीच कहाँ गया।

अगर run ने हर objective पूरा कर लिया तो?

तब भी report करें: measured headroom (target load capacity से कितना नीचे है), वह resource जो अपनी ceiling के सबसे पास था, और पिछले run के मुकाबले trend। सिकुड़ते margin वाला pass एक चेतावनी है।

संदर्भ

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 से लोड टेस्ट कैसे बनाएँ, पैरामीटराइज़ करें और चलाएँ, और उसके लिसनर व रिपोर्ट कैसे पढ़ें।

टूल्स

और गहराई से

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

इस topic से पहले

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

अगले topics

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

परफ़ॉर्मेंस रिज़ल्ट्स का विश्लेषण

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

पहले run जाँचें, फिर curves को एक साथ पढ़ें

Bottleneck खोजें: CPU, memory, database, network

Run को monitoring से correlate करें

Worked example: एक checkout run जो target से चूक गया

ऐसी finding report करें जिस पर कोई काम कर सके

आम गलतियाँ

QA का नज़रिया

अभ्यास

एक search API run का diagnosis करें और finding लिखें

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

संदर्भ

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

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

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

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

टाइमस्टैम्प कन्वर्टर

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

और गहराई से

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

इस topic से पहले

अगले topics

इस मॉड्यूल के दूसरे topics

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

पहले run जाँचें, फिर curves को एक साथ पढ़ें

Bottleneck खोजें: CPU, memory, database, network

Run को monitoring से correlate करें

Worked example: एक checkout run जो target से चूक गया

ऐसी finding report करें जिस पर कोई काम कर सके

आम गलतियाँ

QA का नज़रिया

अभ्यास

एक search API run का diagnosis करें और finding लिखें

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

संदर्भ

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

और गहराई से

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

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

इस topic से पहले

अगले topics

इस मॉड्यूल के दूसरे topics