k6 और JMeter में लोड टेस्टिंग के लिए प्रॉक्सी

जब लोड परीक्षण रेट-लिमिट, WAF या भौगोलिक संतुलन पर अटक जाता है, तो पहला विचार होता है — "मैं विभिन्न IP से ट्रैफ़िक चलाऊँगा।" यह तार्किक लगता है, लेकिन व्यावहारिक रूप से, k6 और JMeter में प्रॉक्सी एक संकीर्ण सेट कार्यों को हल करते हैं, और बाकी को परीक्षण की वास्तुकला से ठीक करना पड़ता है। इस लेख में, हम देखेंगे कि तकनीकी रूप से दोनों उपकरणों में प्रॉक्सी को कैसे कनेक्ट किया जाए, इसके लिए कौन से IP प्रकार उपयुक्त हैं और प्रॉक्सी सर्वर की जिम्मेदारी का क्षेत्र कहाँ समाप्त होता है।

लोड परीक्षण के लिए विभिन्न IP की आवश्यकता क्यों है

डिफ़ॉल्ट रूप से, k6 और JMeter सभी ट्रैफ़िक को एक ही IP पते से भेजते हैं - उस सर्वर से, जिस पर परीक्षण चल रहा है (या CI/CD में क्लाउड मशीन)। यह 90% परिदृश्यों के लिए सामान्य है, लेकिन कुछ मामलों में एक IP पर्याप्त नहीं है:

IP स्तर पर रेट-लिमिटिंग। कई API और लोड बैलेंसर (nginx limit_req, AWS WAF, Cloudflare) प्रति सेकंड एक पते से अनुरोधों की संख्या को सीमित करते हैं। वास्तविक उपयोगकर्ता हजारों विभिन्न IP से आते हैं, जबकि आपका परीक्षण एक से आता है - और यह वास्तविक एप्लिकेशन की बोतल की गर्दन से पहले ही सीमा तक पहुँच जाता है।
भौगोलिक रूप से निर्भर लॉजिक का परीक्षण। CDN, लक्षित सामग्री, क्षेत्रीय मूल्य, geo-ब्लॉकिंग - इन सभी की जांच विशिष्ट देशों के IP से की जानी चाहिए, न कि उस डेटा सेंटर से, जहाँ आपका परीक्षण रनर भौतिक रूप से स्थित है।
लोड बैलेंसर और एनीकास्ट नेटवर्क का परीक्षण। यदि बुनियादी ढांचा IP ग्राहक के आधार पर क्षेत्रों में ट्रैफ़िक वितरित करता है, तो एक पते से परीक्षण केवल एक मार्ग की जांच करेगा, न कि पूरे नेटवर्क की।
वास्तविक ट्रैफ़िक वितरण का अनुकरण। उत्पादन ट्रैफ़िक IP प्रदाताओं, उप-नेटवर्कों, कभी-कभी मोबाइल ऑपरेटरों के बीच वितरित होता है - यह CDN, कैश और एज लॉजिक के व्यवहार को प्रभावित करता है।

यह तुरंत स्पष्ट करना महत्वपूर्ण है: यदि आप बैकएंड के प्रदर्शन का परीक्षण कर रहे हैं (आपका API कितने RPS सहन करेगा), तो प्रॉक्सी लगभग कभी आवश्यक नहीं होते - वहाँ शुद्ध लोड महत्वपूर्ण है, स्रोतों की विविधता नहीं। प्रॉक्सी तब आवश्यक होते हैं जब परीक्षण परिदृश्य वास्तव में ग्राहक के IP पते पर निर्भर करता है।

कौन से प्रॉक्सी उपयुक्त हैं: डेटा सेंटर, आवासीय, मोबाइल

प्रॉक्सी के प्रकार का चयन सीधे इस बात पर प्रभाव डालता है कि आप वास्तव में क्या परीक्षण कर रहे हैं - बुनियादी ढांचे की बैंडविड्थ या "जीवित" IP के तहत प्रणाली का व्यवहार।

प्रॉक्सी का प्रकार	लेटेंसी और गति	लोड परीक्षण में कब उपयोग करें
डेटा सेंटर प्रॉक्सी	कम लेटेंसी, उच्च बैंडविड्थ	रेट-लिमिट की जांच, "N अनुरोधों के साथ IP" सीमा को बायपास करना, विभिन्न उप-नेटवर्कों से बड़े RPS का उत्पादन करना
आवासीय प्रॉक्सी	लेटेंसी अधिक, गति वास्तविक उपयोगकर्ता के चैनल द्वारा सीमित	भौगोलिक लॉजिक का परीक्षण, CDN और एंटी-बॉट सिस्टम की जांच, जो आवासीय रेंज पर डेटा सेंटर की तुलना में अधिक भरोसा करते हैं
मोबाइल प्रॉक्सी	सबसे अधिक लेटेंसी, अस्थिर गति	विशिष्ट परिदृश्य: मोबाइल API का परीक्षण, IP के बार-बार परिवर्तन पर व्यवहार (ऑपरेटर ग्राहक के पते को गतिशील रूप से बदलते हैं)

RPS और रेट-लिमिट की शुद्ध जांच के लिए लगभग हमेशा डेटा सेंटर प्रॉक्सी पर्याप्त होते हैं - वे स्थिर कम लेटेंसी प्रदान करते हैं और परीक्षण के परिणामों को बाहरी नेटवर्क अस्थिरता से विकृत नहीं करते हैं। आवासीय और मोबाइल IP भौगोलिक परीक्षणों में यथार्थता जोड़ते हैं, लेकिन अपनी खुद की लेटेंसी लाते हैं, जिसे मेट्रिक्स के विश्लेषण के दौरान ध्यान में रखना होगा - अन्यथा "प्रॉक्सी नेटवर्क को धीमा कर रही है" और "आपका सर्वर धीमा कर रहा है" में आसानी से भ्रमित हो सकते हैं।

k6 में प्रॉक्सी सेटअप

k6 एक JavaScript उपकरण है (इंजन Go में लिखा गया है, स्क्रिप्ट JS में लिखी जाती हैं), और डिफ़ॉल्ट रूप से स्क्रिप्ट विकल्पों के माध्यम से HTTP प्रॉक्सी का अंतर्निहित समर्थन नहीं है: k6 में प्रॉक्सी को पर्यावरण चर या सिस्टम सेटिंग्स के माध्यम से सेट किया जाता है, क्योंकि कवर के तहत k6 Go HTTP क्लाइंट का उपयोग करता है।

सबसे सरल तरीका - पर्यावरण चर:

export HTTP_PROXY="http://login:password@proxy-host:port"
export HTTPS_PROXY="http://login:password@proxy-host:port"

k6 run script.js

यह तरीका परीक्षण के सभी ट्रैफ़िक को एक प्रॉक्सी के माध्यम से निर्देशित करेगा - यदि आपको बस "सफेद" IP सर्वर से बाहर जाने की आवश्यकता है तो उपयुक्त है। लेकिन यदि कार्य है - विभिन्न IP पर आभासी उपयोगकर्ताओं (VU) का वितरण करना, तो प्रॉक्सी की एक सूची और स्क्रिप्ट स्तर पर चयन की तर्क की आवश्यकता है। सीधे k6 "बॉक्स से बाहर" प्रति-VU प्रॉक्सी का समर्थन नहीं करता है, इसलिए एक सामान्य обход तरीका है - कई k6 प्रक्रियाओं को समानांतर में चलाना, प्रत्येक के साथ अपनी पर्यावरण चर और अपने प्रॉक्सी के साथ पूल से:

// run-with-proxies.sh
PROXIES=("proxy1:port" "proxy2:port" "proxy3:port")

for proxy in "${PROXIES[@]}"; do
  HTTP_PROXY="http://user:pass@$proxy" \
  HTTPS_PROXY="http://user:pass@$proxy" \
  k6 run --vus 50 --duration 5m script.js &
done
wait

यह दृष्टिकोण k6 Cloud के साथ या Kubernetes/Docker Compose के माध्यम से ऑर्केस्ट्रेशन के साथ अच्छी तरह से स्केल करता है - प्रत्येक कंटेनर अपनी प्रॉक्सी चर के साथ उठता है। यदि एक स्क्रिप्ट के एक ही रन के भीतर IP रोटेशन की आवश्यकता है, तो प्रॉक्सी प्रदाता की ओर से रोटेशन लेना अधिक तार्किक है (TTL के साथ स्टिकी सत्र), न कि JS कोड के भीतर रोटेशन बनाने के लिए।

JMeter में प्रॉक्सी सेटअप

JMeter में प्रॉक्सी को नाटकीय रूप से, पर्यावरण चर के बिना, HTTP Request Defaults तत्व के माध्यम से या सीधे HTTP Request Sampler की सेटिंग में सेट किया जाता है:

Thread Group में HTTP Request Defaults कॉन्फ़िगरेशन तत्व जोड़ें।
Proxy Server फ़ील्ड में प्रॉक्सी का होस्ट और पोर्ट निर्दिष्ट करें।
यदि प्रॉक्सी को प्रमाणीकरण की आवश्यकता है - तो उस होस्ट के लिए लॉगिन और पासवर्ड के साथ HTTP Authorization Manager तत्व जोड़ें।
Thread Group के भीतर सभी HTTP Request Samplers स्वचालित रूप से प्रॉक्सी सेटिंग्स को विरासत में लेंगे।

JMeter में कई प्रॉक्सी के माध्यम से लोड वितरण के लिए CSV Data Set Config का उपयोग करना सुविधाजनक है - प्रॉक्सी की सूची वाला फ़ाइल प्रत्येक थ्रेड के लिए होस्ट और पोर्ट के चर में डाला जाता है:

proxy_host,proxy_port,proxy_user,proxy_pass
proxy1.example.com,8000,user1,pass1
proxy2.example.com,8000,user2,pass2
proxy3.example.com,8000,user3,pass3

CSV Data Set Config को Thread Group से कनेक्ट करें, प्रॉक्सी सर्वर/प्रॉक्सी पोर्ट सैंपलर के फ़ील्ड में ${proxy_host} और ${proxy_port} चर निर्दिष्ट करें - प्रत्येक JMeter थ्रेड फ़ाइल से अपनी पंक्ति लेगा और अपने IP के माध्यम से जाएगा। कमांड लाइन के माध्यम से चलाने के लिए (हेडलेस मोड, जो वास्तविक लोड परीक्षण के लिए अनुशंसित है) प्रॉक्सी को भी फ़्लैग के रूप में पास किया जा सकता है:

jmeter -n -t test_plan.jmx -l results.jtl \
  -H proxy-host -P port \
  -u username -a password

यह तरीका पूरे परीक्षण के लिए एक सामान्य प्रॉक्सी सेट करता है - कई प्रॉक्सी परिदृश्यों के लिए, आपको CSV Data Set Config या Distributed Testing (कई JMeter-गुलाम, प्रत्येक अपने प्रॉक्सी के साथ कॉन्फ़िगरेशन में) का उपयोग करना होगा।

IP रोटेशन और लोड वितरण

लोड परीक्षण में IP के वितरण के लिए दो मौलिक रूप से अलग दृष्टिकोण हैं:

स्टैटिक IP को थ्रेड/VU से जोड़ना। प्रत्येक आभासी उपयोगकर्ता पूरे सत्र के लिए एक ही IP प्राप्त करता है - यह एक पते वाले वास्तविक उपयोगकर्ता का अनुकरण करता है। इसे स्टिकी-सेशन प्रॉक्सी या बस CSV/पर्यावरण चर में एक निश्चित सूची के माध्यम से सेट किया जाता है।
प्रत्येक अनुरोध पर IP रोटेशन। प्रॉक्सी प्रत्येक HTTP अनुरोध पर आउटगोइंग पते को बदलता है - यह रेट-लिमिट से सुरक्षा की जांच के लिए उपयोगी है, लेकिन वास्तविक उपयोगकर्ताओं के व्यवहार को कमजोर रूप से दर्शाता है, जिनका IP हर सेकंड नहीं बदलता।

यथार्थवादी लोड परीक्षण के लिए, 90% मामलों में, VU/थ्रेड के लिए पूरे सत्र के लिए IP को जोड़ना सही होता है - इस तरह परीक्षण स्वतंत्र उपयोगकर्ताओं की संख्या के व्यवहार को ईमानदारी से दर्शाता है, न कि कृत्रिम शोर उत्पन्न करता है। प्रत्येक अनुरोध पर रोटेशन केवल संकीर्ण परिदृश्यों में शामिल करने का अर्थ है - उदाहरण के लिए, रेट-लिमिट नियम के सक्रियण की लक्षित जांच के दौरान।

प्रॉक्सी निश्चित रूप से क्या नहीं बदलेंगे

यहाँ लेख का मुख्य बिंदु है: प्रॉक्सी "किस IP से अनुरोध आता है" की समस्या को हल करते हैं, लेकिन उन समस्याओं को हल नहीं करते हैं, जिन्हें वास्तव में लोड परीक्षण द्वारा जांचा जाता है।

आपके परीक्षण रनर की बैंडविड्थ। यदि लोड जनरेटर (k6/JMeter के साथ मशीन) CPU, मेमोरी या नेटवर्क कार्ड पर अटक जाता है - प्रॉक्सी इसे ठीक नहीं करेंगे। प्रॉक्सी अतिरिक्त नेटवर्क हॉप और अपनी लेटेंसी जोड़ते हैं, और रनर से लोड को कम नहीं करते हैं।
परीक्षित सर्वर की वास्तविक बैंडविड्थ। सर्वर या तो लोड को सहन करता है या नहीं - ग्राहक का IP पता इस पर प्रभाव नहीं डालता, स्पष्ट IP द्वारा रेट-लिमिट के मामलों को छोड़कर।
प्रतिक्रिया समय के मेट्रिक्स की विश्वसनीयता। प्रॉक्सी अपनी लेटेंसी जोड़ते हैं (विशेष रूप से आवासीय और मोबाइल), जो आपके रिपोर्ट में प्रतिक्रिया समय के भाग के रूप में आएगी। यदि प्रॉक्सी की लेटेंसी को अलग से नहीं घटाया गया, तो अंतिम लेटेंसी रिपोर्ट विकृत होगी और उत्पादन मेट्रिक्स के साथ तुलना के लिए अनुपयुक्त होगी।
वास्तविक ट्रैफ़िक के तहत बुनियादी ढांचे का स्केलिंग। प्रॉक्सी के साथ लोड परीक्षण एक निश्चित अनुरोध पैटर्न के तहत व्यवहार को दिखाता है, लेकिन यह क्षमता योजना, ऑटो-स्केलिंग और वास्तविक उत्पादन लॉग पर आधारित लोड प्रोफाइल को प्रतिस्थापित नहीं करता है।
लोड के तहत व्यवसायिक लॉजिक की सटीकता की जांच। रेस कंडीशंस, डेटाबेस में लॉक, कतारों में गिरावट - ये प्रतिस्पर्धात्मकता और प्रोफाइलिंग पर परीक्षणों में होते हैं, न कि आउटगोइंग IP को बदलने में।

प्रॉक्सी एक निजी कार्य के लिए उपकरण हैं "विभिन्न IP से ट्रैफ़िक का अनुकरण करना", न कि लोड परीक्षण के लिए एक सार्वभौमिक प्रवर्धक। यदि लक्ष्य यह समझना है कि बैकएंड कितने RPS सहन करेगा, तो अधिकांश मामलों में प्रॉक्सी की आवश्यकता नहीं है: कुछ परीक्षण रनर बिना प्रॉक्सी के, सही तरीके से सेट किए गए कीप-एलाइव और कनेक्शन पूल के साथ पर्याप्त हैं।

प्रॉक्सी के माध्यम से परीक्षण करते समय सामान्य गलतियाँ

व्यावहारिक रूप से, लोड परीक्षण में प्रॉक्सी के साथ अधिकांश समस्याएँ कुछ दोहराए जाने वाली गलतियों तक सीमित होती हैं।

प्रॉक्सी की लेटेंसी को परीक्षण सेवा की लेटेंसी के साथ मिलाना। बिना बेसलाइन माप (प्रॉक्सी के बिना सीधा अनुरोध) यह समझना असंभव है कि प्रॉक्सी सर्वर स्वयं कितने मिलीसेकंड जोड़ता है।
जहाँ शुद्ध बैंडविड्थ की आवश्यकता होती है, वहाँ मोबाइल या आवासीय प्रॉक्सी का उपयोग करना। ऐसे प्रॉक्सी अंतिम उपकरण के वास्तविक चैनल से सीमित होते हैं और भौतिक रूप से हजारों RPS का समर्थन नहीं कर सकते - शुद्ध लोड के लिए डेटा सेंटर प्रॉक्सी की आवश्यकता होती है।
बड़े संख्या में VU के लिए IP का अपर्याप्त पूल। यदि 5000 आभासी उपयोगकर्ताओं के लिए 10 प्रॉक्सी पते हैं, तो परीक्षण फिर भी उसी रेट-लिमिट पर अटक जाएगा, बस लेटेंसी के साथ - सेवा जल्दी "10 IP, हजारों अनुरोध" पैटर्न को देखेगी।
प्रॉक्सी के पक्ष पर टाइमआउट की अनदेखी करना। उच्च प्रतिस्पर्धात्मक लोड के दौरान, प्रॉक्सी सर्वर स्वयं कनेक्शनों को अस्वीकार करना शुरू कर सकता है - प्रॉक्सी प्रदाता से समवर्ती सत्रों की सीमाओं की पहले से पुष्टि करना महत्वपूर्ण है।
व्हाइटलिस्टिंग/प्रमाणीकरण की जांच किए बिना परीक्षण शुरू करना। यदि प्रॉक्सी IP के माध्यम से प्रमाणीकरण की आवश्यकता है, और परीक्षण CI/CD से एक गतिशील पते के साथ शुरू होता है - अनुरोध 407 प्रॉक्सी प्रमाणीकरण की आवश्यकता के साथ गिरेंगे, और परीक्षण के परिणाम बेकार हो जाएंगे।

परीक्षण शुरू करने से पहले चेकलिस्ट

यह निर्धारित किया कि क्या कार्य वास्तव में विभिन्न IP की आवश्यकता है, या एक पते से परीक्षण पर्याप्त है।
कार्य के लिए प्रॉक्सी का प्रकार चुना: RPS और रेट-लिमिट के लिए डेटा सेंटर, भौगोलिक लॉजिक के लिए आवासीय/मोबाइल।
प्रॉक्सी के बिना बेसलाइन माप किया, ताकि नेटवर्क की लेटेंसी को प्रॉक्सी की लेटेंसी से अलग किया जा सके।
आवश्यक VU स्तर के लिए प्रॉक्सी प्रदाता के साथ समवर्ती कनेक्शनों की सीमाओं की जांच की।
प्रॉक्सी प्रमाणीकरण (लॉगिन/पासवर्ड या रनर के IP की व्हाइटलिस्टिंग) सेट किया।
निर्धारित किया कि क्या VU पर स्टिकी सत्र की आवश्यकता है या प्रत्येक अनुरोध पर रोटेशन।
कॉन्फ़िगरेशन की जांच के लिए पूर्ण रन से पहले छोटे अंतराल (1-2 मिनट) पर परीक्षण चलाया।

निष्कर्ष

k6 और JMeter में प्रॉक्सी विभिन्न IP पतों से ट्रैफ़िक का अनुकरण करने, रेट-लिमिट और भौगोलिक रूप से निर्भर लॉजिक के व्यवहार की जांच करने का एक कार्यशील तरीका है। लेकिन यह लोड परीक्षण की समझदारी योजना का विकल्प नहीं है: सर्वर की बैंडविड्थ, प्रतिस्पर्धात्मक लोड के तहत बैकएंड की स्थिरता और वास्तविक क्षमता योजना को प्रॉक्सी नहीं जांचते और न ही सुधारते हैं। उनका उपयोग लक्षित रूप से करें - जहाँ परीक्षण वास्तव में ग्राहक के IP पते पर निर्भर करता है, न कि "ईमानदारी" के लिए एक सार्वभौमिक उपकरण के रूप में।

यदि कार्य IP पर सीमाओं की जांच करना और उच्च बैंडविड्थ के साथ बड़े पैमाने पर ट्रैफ़िक का अनुकरण करना है, तो डेटा सेंटर प्रॉक्सी से शुरू करना समझदारी है - वे न्यूनतम लेटेंसी प्रदान करते हैं और बड़ी संख्या में समवर्ती सत्रों को सहन करते हैं। भौगोलिक लॉजिक और एंटी-बॉट सिस्टम की ट्रैफ़िक के स्रोत पर विश्वास के लिए बंधे परीक्षणों के लिए, आवासीय प्रॉक्सी अधिक उपयुक्त हैं, और मोबाइल ट्रैफ़िक के साथ विशिष्ट परिदृश्यों के लिए - मोबाइल IP।