मोबाइल डेवलपमेंट में Load Test — यह क्या है, परिदृश्य और कैसे किया जाता है

Load Test क्या है?

Load Test यह सत्यापित करने की प्रक्रिया है कि एक सिस्टम अपेक्षित संख्या में एकसाथ अनुरोधों या उपयोगकर्ताओं के तहत कैसा प्रदर्शन करता है। मोबाइल डेवलपमेंट के संदर्भ में, Load Test सर्वर-साइड (API, डेटाबेस, कैश) और क्लाइंट-साइड (push नोटिफिकेशन प्रसेसिंग, डेटा सिंक्रोनाइजेशन) दोनों पर लागू होता है। स्ट्रेस टेस्टिंग से मुख्य अंतर यह है कि Load Test वास्तविक, चरम नहीं, लोड का अनुकरण करता है। AWS Well-Architected Framework (2024) के अनुसार, लोड टेस्टिंग वास्तविक उपयोग विश्लेषण पर आधारित लोड प्रोफाइल का उपयोग करके किया जाना चाहिए।

Load Test HTTP अनुरोधों, WebSocket कनेक्शन्स या डेटाबेस लेनदेन के स्तर पर किया जा सकता है। लक्ष्य यह सुनिश्चित करना है कि प्रत्येक अनुरोध का प्रतिक्रिया समय एक निर्दिष्ट सीमा (आमतौर पर API के लिए 500–1000 मिलीसेकंड) से अधिक न हो, और थ्रूपुट (RPS — अनुरोध प्रति सेकंड) आवश्यकताओं को पूरा करता है। Google Cloud Armor (2024) प्रतिशतक के आधार पर सीमा मान परिभाषित करता है: महत्वपूर्ण एंडपॉइंट्स के लिए p95 प्रतिक्रिया समय 2 सेकंड से अधिक नहीं होना चाहिए।

मोबाइल बैकेंड का लोड टेस्टिंग विशिष्ट परिदृश्यों का अनुकरण शामिल करता है: पंजीकरण, प्रमाणीकरण, फीड लोडिंग, फॉर्म सबमिशन। परिदृश्य HAR फाइलों (HTTP Archive) के रूप में रिकॉर्ड किए जाते हैं और लोड टेस्टिंग टूल द्वारा दोबारा चलाए जाते हैं। k6 डॉक्यूमेंटेशन (2025) के अनुसार, HAR रूपान्तरण Load Test तैयारी के समय को 60% तक कम कर सकता है।

लोड टेस्टिंग के लक्ष्य

Load Test का पहला लक्ष्य सिस्टम थ्रूपुट की पुष्टि करना है। यदि विनिर्देश 1000 RPS संभालने की आवश्यकता है, तो लोड टेस्ट को 20% बफर के साथ इसकी पुष्टि करनी चाहिए। Netflix Tech Blog (2024) के अनुसार, Netflix में लोड टेस्टिंग पीक लोड से 2x बफर के साथ किया जाता है: यदि 10000 RPS की उम्मीद है, तो परीक्षण 20000 RPS की जाँच करता है। यह दृष्टिकोण अचानक ट्रैफिक उतार-चढ़ाव के दौरान स्थिरता सुनिश्चित करता है।

दूसरा लक्ष्य आर्किटेक्चर में अवरोधकों (bottlenecks) की पहचान करना है। मोबाइल बैकेंड में विशिष्ट अवरोधक हैं: डेटाबेस (धीमी क्वेरीज), कैश (गलत अमान्य रणनीति), और बाहरी API (धीमी तीसरे पक्ष की सेवाएँ)। वितरण ट्रेसिंग (Jaeger, Zipkin) किसी विशिष्ट सेवा या अनुरोध के स्तर पर समस्या को स्थानीकृत करने में मदद करता है।

तीसरा लक्ष्य संतृप्ति बिंदु (saturation point) निर्धारित करना है। यह वह क्षण है जब नए उपयोगकर्ताओं को जोड़ने से थ्रूपुट में वृद्धि नहीं होती। मोबाइल एप्लिकेशनों में, संतृप्ति बिंदु अक्सर डेटाबेस सर्वरों पर 70–80% CPU लोड पर होता है। ऑटो-स्केलिंग को इस बिंदु तक पहुँचने से पहले सक्रिय होना चाहिए।

लोड टेस्टिंग परिदृश्य

स्पाइक टेस्ट (Spike Test) — गतिविधि में अचानक उतार-चढ़ाव का अनुकरण करता है, जैसे सुबह का push नोटिफिकेशन ब्लास्ट या विज्ञापन अभियान शुरू करना। Grafana k6 (2025) के अनुसार, Spike Test 30 सेकंड में 100 से 10000 RPS तक लोड वृद्धि का अनुकरण करता है। सिस्टम को अनुरोधों को खोए बिना और प्रतिक्रिया समय को 50% से अधिक बढ़ाए बिना इसे संभालना चाहिए।

एंडुरंस टेस्ट (Endurance Test) — लंबे समय तक लोड के तहत सिस्टम स्थिरता की जाँच करता है। विशिष्ट अवधि 1–4 घंटे है। Endurance Test सर्वर एप्लिकेशनों में मेमोरी लीक, डेटाबेस कनेक्शन पूल समस्याएँ और कैश प्रदर्शन गिरावट का पता लगाता है। PostgreSQL कनेक्शन पूल उचित कॉन्फ़िगरेशन के बिना लंबे लोड के तहत 2–3 घंटे में उपलब्ध कनेक्शन्स को समाप्त कर सकती है।

स्टेप लोड टेस्ट (Step Load Test) — हर 2–5 मिनट में 10–20% के कडम के साथ क्रमशः लोड वृद्धि। यह परिदृश्य सही सीमा खोजने में मदद करता है जिसके बाद सिस्टम ख़राब हो जाता है। InfluxDB और Prometheus प्रतिक्रिया समय बनाम RPS ग्राफ़ बनाने के लिए प्रत्येक कडम पर मैट्रिक्स एकत्रित करते हैं।

Load Test मैट्रिक्स

प्रतिक्रिया समय

प्रतिक्रिया समय (Response Time) Load Test का प्राथमिक मैट्रिक है। मिलीसेकंड में मापा जाता है और प्रतिशतक द्वारा विश्लेषित किया जाता है: p50 (माध्यिका), p95 और p99। Google SRE (2024) REST API के लिए 1000 मिलीसेकंड से अधिक नहीं और gRPC के लिए 200 मिलीसेकंड से अधिक नहीं की p95 सीमा की अनुशंसा करता है। प्रतिशतक औसत से अधिक महत्वपूर्ण हैं क्योंकि वे सबसे खराब अनुरोधों के व्यवहार को दिखाते हैं, जिसे उपयोगकर्ता सबसे पहले नोटिस करते हैं। Apdex (एप्लिकेशन प्रदर्शन सूचकांक) एक मिश्रित मैट्रिक है जो संतुष्ट, सहनशील और निराश उपयोगकर्ताओं के अनुपात पर विचार करता है।

थ्रूपुट

थ्रूपुट (Throughput) — समय की एक इकाई में सफल अनुरोधों की संख्या। RPS (अनुरोध प्रति सेकंड) या TPS (लेनदेन प्रति सेकंड) में मापा जाता है। निर्देशांक “समय — RPS” में Throughput ग्राफ़ संतृप्ति बिंदु तक रैखिक होना चाहिए। बढ़ते लोड के साथ Throughput में तेज गिरावट सिस्टम की सीमा तक पहुँचने का संकेत है। Apache Bench और wrk विकास के दौरान त्वरित Throughput जाँच के लिए सरल CLI औजार हैं।

त्रुटि दर

त्रुटि दर (Error Rate) — कुल अनुरोधों में HTTP स्थिति 4xx या 5xx वाले प्रतिक्रियाओं का अनुपात। स्वीकार्य सीमा 1% से कम है। उच्च लोड के तहत त्रुटियाँ 429 (Too Many Requests) और 503 (Service Unavailable) रेट लिमिटिंग और ऑटो-स्केलिंग को कॉन्फ़िगर करने की आवश्यकता को इंगित करती हैं। API Gateway पर रेट लिमिटर बैकेंड को अनुमत लोड से अधिक होने से बचाता है। एक्सपोनेंशियल बैकऑफ के साथ रिट्री नीति क्लाइंट को अस्थायी त्रुटियों को सही ढंग से संभालने में मदद करती है।

Load Test के लिए औजार

k6 (Grafana)

k6 — Grafana से अग्रगणी ओपन सॉर्स लोड टेस्टिंग टूल। स्क्रिप्ट JavaScript में लिखे जाते हैं, मॉड्यूलर परिदृश्य, थ्रेशॉल्ड्स और Prometheus और InfluxDB के साथ एकीकरण का समर्थन करता है। k6 CLI और Grafana Cloud k6 दोनों में चलाया जा सकता है। Grafana Cloud Load Test परिणामों से स्वचालित रूप से डैशबोर्ड बनाता है और उनकी तुलना ऐतिहासिक डेटा से करता है। k6 एक अलग k6/net/grpc मॉड्यूल के माध्यम से Protocol Buffers और gRPC का समर्थन करता है।

Apache JMeter

Apache JMeter — ग्राफिक्सल इंटरफ़ेस के साथ एक क्लासिक्यल Load Test टूल। यह प्रोटोकॉल की एक व्यापक श्रृंखला का समर्थन करता है: HTTP, JDBC, JMS, FTP और TCP। JMeter कई प्रकार के अनुरोधों के साथ जटिल परिदृश्यों के लिए बेहतर उपयुक्त है लेकिन k6 की तुलना में अधिक मैनुअल कॉन्फ़िगरेशन की आवश्यकता होती है। JMeter प्लगइन्स WebSocket और gRPC परीक्षण के लिए कार्यक्षमता बढ़ाते हैं। वितरित निष्पादन के लिए, JMeter एक नियंत्रक के साथ मास्टर-स्लेव आर्किटेक्चर का उपयोग करता है।

Locust

Locust — Python-आधारित टूल जो कोड में लोड परिदृश्यों का वर्णन करने की अनुमति देता है। Locust उन टीमों के लिए सुविधाजनक है जो अपनी प्रमुख ऑटोमेशन भाषा के रूप में Python का उपयोग करती हैं। k6 और JMeter के विपरीत, Locust बॉक्स से ही वितरित निष्पादन का समर्थन करता है: एक मास्टर नॉड कई वर्कर नॉड्स का समन्वय करता है। वितरित निष्पादन एकाधिक मशीनों से 100000 RPS तक लोड उत्पन्न करने की अनुमति देता है। Locust कस्टम एक्सटेंशन्स के माध्यम से WebSocket परीक्षण का भी समर्थन करता है।

import http from 'k6/http'
import check from 'k6'
import sleep from 'k6'

export const options = {
    stages: [
        { duration: '2m', target: 100 },
        { duration: '5m', target: 100 },
        { duration: '2m', target: 200 },
    ],
    thresholds: {
        http_req_duration: ['p(95)<500'],
        http_req_failed: ['rate<0.01'],
    }
}

export default function() {
    const res = http.get('https://api.example.com/users')
    check(res, {
        'status is 200': (r) => r.status === 200,
    })
    sleep(1)
}

k6 में Load Test लिखने का उदाहरण

ऊपर दिखाया गया k6 स्क्रिप्ट एक विशिष्ट लोड टेस्ट संरचना का प्रदर्शन करता है। Options लोड प्रोफ़ाइल परिभाषित करता है: दो मिनट में रैम्प-अप करके 100 उपयोगकर्ताओं तक, फिर 5 मिनट स्थिर लोड, और फिर रैम्प-अप करके 200 उपयोगकर्ताओं तक। थ्रेशॉल्ड्स परीक्षण पास करने के मानदंड परिभाषित करते हैं: p95 अनुरोध समय 500 मिलीसेकंड से अधिक नहीं, त्रुटि दर 1% से कम। यदि थ्रेशॉल्ड्स पार हो जाते हैं, तो k6 गैर-शून्य कोड के साथ बाहर निकलता है — यह Load Test को CI/CD में एकीकृत करने की अनुमति देता है।

मोबाइल डेवलपमेंट में, नई सुविधाओं को लॉन्च करते समय सर्वर-साइड का Load Test विशेष रूप से महत्वपूर्ण है जो अतिरिक्त लोड बनाती हैं: लाइक, टिप्पणी, स्ट्रिमिंग। अनुशंसा — प्रोडक्शन में डिप्लॉय करने से पहले प्रत्येक staging पर Load Test आयोजित करें। API डिजाइन चरण के दौरान एक बेसलाइन लोड प्रोफ़ाइल बनाने से बाद के चरणों में आर्किटेक्चरल समस्याओं से बचने में मदद मिलती है।