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

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

App की हर screen और हर partner integration API calls की एक chain है, इसलिए एक धीमा endpoint उसे call करने वाली हर screen को धीमा कर देता है, और sequential calls में delays जुड़ते जाते हैं। Unbounded list या किसी popular row पर lock जैसी समस्याएँ functional tests में दिखती ही नहीं, क्योंकि वे थोड़े data के साथ एक बार में एक request भेजते हैं।

Tester के लिए endpoint targets "app धीमा लगता है" को एक reportable result में बदल देते हैं: कौन-सा endpoint, कौन-सा percentile, किस load पर, किस target के मुकाबले। API-level tests endpoint बनते ही शुरू हो सकते हैं, पूरे end-to-end load test से बहुत पहले।

पूरे API का नहीं, हर endpoint का अपना target

Endpoints बहुत अलग-अलग काम करते हैं: health check एक constant लौटाता है, lookup एक row पढ़ता है, search हज़ारों records filter करता है, और order बनाना कई tables में लिखता है और शायद payment provider को call करता है। "पूरे API" के लिए एक target, जैसे "सब कुछ 500 ms से कम", हल्के endpoints का regression छिपा देता है और भारी endpoints के लिए असंभव होता है।

Testable target में endpoint और method, percentile (p95, अक्सर p99 भी), threshold, वह load जिस पर target लागू हो, स्वीकार्य error rate और data condition, जैसे page size, सब लिखे होते हैं। Load level के बिना "p95 200 ms से कम" न pass हो सकता है न fail। Targets non-functional requirements या SLOs से, client की ज़रूरत से (जो screen दो endpoints को एक के बाद एक call करती है, उसे अपना time budget बाँटना पड़ता है) और production monitoring से आते हैं। Table एक team का उदाहरण है, कोई standard नहीं।

बड़े export जैसा धीमा काम request को खुला नहीं रखना चाहिए। एक आम design तुरंत 202 Accepted लौटाता है (RFC 9110: processing के लिए स्वीकार, पर पूरी नहीं हुई) और client result बाद में लेता है; तब आप दो targets टेस्ट करते हैं: स्वीकार करने का समय और result तैयार होने तक का समय।

Shop API: targets at the expected peak (an example agreed by one team)

Endpoint                      Load        p95       p99       Errors
GET  /health                  20 req/s    <= 50 ms  <= 100 ms 0 %
GET  /products/{id}           150 req/s   <= 200 ms <= 400 ms < 0.1 %
GET  /products?q=...&limit=20 60 req/s    <= 500 ms <= 1 s    < 0.1 %
POST /orders                  10 req/s    <= 800 ms <= 1.5 s  < 0.1 %
POST /reports/export          1 req/min   202 Accepted <= 300 ms; file ready <= 60 s

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

Payload size भी response time का हिस्सा है

Client को दिखने वाले response time में body बनाना, भेजना और parse करना शामिल है। वही endpoint 20 items के साथ तेज़ और 2,000 के साथ धीमा हो सकता है, office network पर तेज़ और mobile connection पर धीमा। हर endpoint को उन sizes पर टेस्ट करें जो वह सच में भेजेगा और लेगा।

• Body को raw भी मापें और transfer होते समय भी: जब client Accept-Encoding: gzip भेजे, तो क्या response में Content-Encoding है, और उससे कितने bytes बचते हैं?
• Lists bounded होनी चाहिए: default page size, documented maximum और उससे ऊपर की एक value टेस्ट करें। limit=100000 को cap या reject होना चाहिए, serve नहीं।
• Data बढ़ाएँ: वही endpoint 5 orders वाले customer और 5,000 orders वाले customer के लिए call करें। Data के साथ बढ़ता समय missing pagination या हर item के लिए एक query की ओर इशारा करता है।
• Request bodies पर boundary value analysis लगाएँ: batch endpoint का समय 1 item, एक typical संख्या और documented maximum के साथ मापें, फिर maximum से एक item ज़्यादा भेजें और धीमे timeout की जगह एक तेज़, documented 4xx की उम्मीद करें। Server की size limit से बड़ी body के लिए RFC 9110 413 Content Too Large define करता है।

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

Concurrency: एक तेज़ request बहुत कम साबित करती है

Functional API test एक बार में एक request भेजता है, इसलिए वह best case दिखाता है। Concurrency में requests worker threads, database connections, locks और downstream calls के लिए होड़ करती हैं, और जो endpoint अकेले 80 ms में जवाब देता है वह queue में seconds तक रुक सकता है। पिछले lessons के workload models से load को steps में बढ़ाएँ: single-user baseline, फिर expected peak (analytics या business के forecast के हिसाब से सबसे ज़्यादा अपेक्षित traffic), फिर उससे ऊपर, जो stress testing है। हर step पर p95, p99, throughput और error rate record करें।

Requests कहाँ पहुँचती हैं, यह भी मायने रखता है। कई records पर फैली requests normal path टेस्ट करती हैं; एक ही record पर बहुत-सी requests, जैसे sale में एक discounted product, locking टेस्ट करती हैं। दोनों को जानबूझकर design करें: पहले के लिए अलग-अलग test data, दूसरे के लिए एक "hot" record।

• सिर्फ़ timing नहीं, correctness भी जाँचें: हर response का status और मुख्य fields assert करें, और run के बाद side effects देखें, जैसे stock oversell न हुआ हो और client के retry करने पर कोई order दो बार न बना हो।
• Expected refusals को failures से अलग रखें: documented rate limit से ऊपर 429 Too Many Requests (RFC 6585) की उम्मीद करें, और उसे 5xx errors और 504 Gateway Timeout जैसे timeouts से अलग गिनें।

आज़माएँ: Concurrent रिक्वेस्ट टेस्ट जनरेटर

Worked example: sale से पहले एक shop API

एक shop sale वाले weekend की तैयारी कर रहा है। Tester table के product, search और order endpoints को उनके peak rates पर 15 मिनट तक production जैसे size वाले staging environment में चलाता है, 20,000 product ids और 2,000 test customers के साथ, अलग machines पर चल रहे load generators से। Results, जैसे वे report में लिखे जाते हैं:

• GET /products/{id}: p95 140 ms, p99 260 ms, कोई error नहीं। Target के अंदर।
• Default limit=20 के साथ GET /products?q=...: p95 430 ms, target के अंदर। Web app का "show all" button limit=200 भेजता है: 1.8 MB uncompressed और p95 1,900 ms। Finding: कोई maximum page size नहीं।
• कई products पर फैली 10 req/s पर POST /orders: p95 650 ms, target के अंदर। जब 50 virtual users एक साथ एक ही discounted product order करते हैं, तो p95 1,400 ms तक पहुँचता है और 2 % requests 504 Gateway Timeout पर ख़त्म होती हैं। Finding: requests उस product के stock update पर queue में रुकती हैं।
• Run के बाद stock levels orders से मेल खाते हैं: कुछ oversell नहीं हुआ, कुछ duplicate नहीं बना। यहाँ concurrency की समस्या धीमापन है, data corruption नहीं।

Tools: एक request से scripted load test तक

Load test के आसपास के steps छोटे tools से हो जाते हैं। Mutqan का Response Time Analyzer ज़्यादा से ज़्यादा 20 sequential requests से एक endpoint की single-user baseline देता है (min, max, average, median और p95); Response Size Analyzer किसी URL या paste की गई body के लिए raw bytes, अनुमानित compressed size और सबसे बड़े fields दिखाता है; API Performance Comparator दो endpoints को साथ-साथ रखता है; HTTP Request Benchmark एक छोटा, bounded benchmark चलाता है। ये tools अपनी requests Mutqan के server से भेजते हैं, इसलिए सिर्फ़ public URLs तक पहुँचते हैं और उनके timings में उस server से network path भी शामिल होता है। इनमें से कोई भी production-scale load नहीं बनाता।

उसके लिए load generator चाहिए। k6 JavaScript scripts चलाता है जिनके thresholds target छूटने पर run को fail कर देते हैं; Apache JMeter GUI में test plans बनाता है, CSV Data Set Config से test data पढ़ता है और असली test के लिए non-GUI mode में चलना चाहिए; Gatling और Locust (Python) दूसरे आम विकल्प हैं। नीचे की k6 script product lookup का target encode करती है। Load test सिर्फ़ उन systems पर करें जो आपके हैं या जिनके लिए लिखित अनुमति है: third-party provider को बिना बताए किया गया load test denial-of-service attack जैसा दिखता है।

// Run: k6 run -e BASE_URL=https://staging.example.com product-lookup.js
import http from 'k6/http';
import { check } from 'k6';
import { SharedArray } from 'k6/data';

// 20,000 product ids: varied data, so requests do not all hit one cached record
const ids = new SharedArray('ids', () =>
  open('./product-ids.txt').split(/\r?\n/).filter(Boolean));

export const options = {
  scenarios: {
    product_lookup: {
      executor: 'constant-arrival-rate', // open model: a fixed rate of new requests
      rate: 150,
      timeUnit: '1s',
      duration: '15m',
      preAllocatedVUs: 50,
      maxVUs: 300,
    },
  },
  thresholds: {
    'http_req_duration{endpoint:product}': ['p(95)<=200', 'p(99)<=400'],
    'http_req_failed{endpoint:product}': ['rate<0.001'],
  },
};

export default function () {
  const id = ids[Math.floor(Math.random() * ids.length)];
  const res = http.get(`${__ENV.BASE_URL}/products/${id}`, {
    tags: { endpoint: 'product' },
  });
  check(res, {
    'status is 200': (r) => r.status === 200,
    'body has a price': (r) => r.status === 200 && r.json('price') !== undefined,
  });
}

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

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

संदर्भ

• Certified Tester Performance Testing (CT-PT)ISTQB · 2018performance testing पर ISTQB का specialist पाठ्यक्रम: बुनियादी अवधारणाएँ, performance measurements, टेस्ट गतिविधियाँ व कार्य, और टूल।
• RFC 9110: HTTP SemanticsIETF · 2022HTTP मेथड, हेडर फ़ील्ड, स्टेटस कोड और कंटेंट निगोशिएशन के अर्थ, वायर वर्ज़न से स्वतंत्र।
• RFC 6585: Additional HTTP Status CodesIETF · 2012428, 429 Too Many Requests, 431 और 511 को परिभाषित करता है, रेट लिमिटिंग के लिए Retry-After हेडर सहित।
• Grafana k6 documentationGrafana LabsGrafana k6 का आधिकारिक दस्तावेज़ — एक open-source और extensible load व performance testing टूल।