अपने सॉफ़्टवेयर को एंड-यूजर्स के लिए जारी करने से पहले, हम यह सुनिश्चित करने के लिए विभिन्न प्रकार के टेस्ट करते हैं कि एप्लिकेशन बग-फ्री है और व्यावसायिक आवश्यकताओं को पूरा करता है। यद्यपि हम बहुत सारे टेस्ट करते हैं, हम इस बात के लिए निश्चित नहीं हो सकते कि सॉफ़्टवेयर स्थिर है बिना उपयोगकर्ताओं के वास्तव में इसका उपयोग किए। एंड-यूजर्स द्वारा एप्लिकेशन का उपयोग शुरू करने के बाद, विभिन्न चीजें एप्लिकेशन को हमारे अपेक्षा के अनुरूप व्यवहार न करने का कारण बन सकती हैं, निम्नलिखित कारणों में से कुछ के लिए:
- उपयोगकर्ता व्यवहार अप्रत्याशित हो सकता है;
- उपयोगकर्ता विभिन्न स्थानों पर वितरित होते हैं;
- एक बड़ी संख्या में उपयोगकर्ता एक ही समय में एप्लिकेशन का उपयोग कर सकते हैं।
बड़े पैमाने के एप्लिकेशन के लिए, पूर्ण रिलीज़ से पहले इन चीजों को जानना बहुत महत्वपूर्ण है। यह सुनिश्चित करने के लिए कि हमारा एप्लिकेशन अपेक्षा के अनुरूप काम करता है, हमें इसकी कार्यक्षमता को रोल आउट करते समय कुछ चीजों पर विचार करने की आवश्यकता है:
- चरणबद्ध रोलआउट - चरणबद्ध रोलआउट के दौरान, एप्लिकेशन को सभी को कार्यक्षमता तक पहुंच मिलने से पहले उपयोगकर्ताओं के एक छोटे हिस्से द्वारा टेस्ट किया जा सकता है। यह हमें उपयोगकर्ता व्यवहार निर्धारित करने में मदद करेगा।
- लोड टेस्टिंग - चरणबद्ध रोलआउट के दौरान, हम उपयोगकर्ता व्यवहार निर्धारित कर सकते हैं, लेकिन हम यह नहीं जान सकते कि प्लेटफ़ॉर्म कैसे काम करता है जब कई उपयोगकर्ता विभिन्न स्थानों से एक ही समय में एप्लिकेशन का उपयोग करते हैं।
लोड टेस्टिंग क्या है, और यह प्रदर्शन टेस्टिंग से कैसे भिन्न है?
निम्नलिखित तीन शब्द समान लग सकते हैं, लेकिन वे भिन्न हैं:
- प्रदर्शन टेस्टिंग (Performance Testing),
- लोड टेस्टिंग (Load Testing), और
- स्ट्रेस टेस्टिंग (Stress Testing)।
प्रदर्शन टेस्टिंग एक सामान्य टेस्टिंग तंत्र है जिसका उपयोग यह आकलन करने के लिए किया जाता है कि एप्लिकेशन दिए गए इनपुट के साथ कैसा प्रदर्शन करता है। यह एप्लिकेशन का उपयोग करने वाले एकल उपयोगकर्ता या एकाधिक उपयोगकर्ताओं के साथ किया जा सकता है। यह प्रतिक्रिया समय और CPU/मेमोरी उपयोग जैसे कुछ मेट्रिक्स का आकलन करने के लिए आयोजित किया जाता है। लोड/स्ट्रेस टेस्टिंग प्रदर्शन टेस्टिंग का एक सबसेट है।
लोड टेस्टिंग यह सुनिश्चित करने के लिए आयोजित की जाती है कि एप्लिकेशन निर्दिष्ट समय अवधि में एप्लिकेशन का समवर्ती रूप से उपयोग करने वाले उपयोगकर्ताओं की एक निर्दिष्ट संख्या के साथ अपेक्षा के अनुरूप प्रदर्शन करता है। यह निर्धारित करने में मदद करता है कि एक सिस्टम कितने उपयोगकर्ताओं को संभाल सकता है।
स्ट्रेस टेस्टिंग और लोड टेस्टिंग एक दूसरे से निकटता से संबंधित हैं। स्ट्रेस टेस्टिंग लोड टेस्टिंग के समान तंत्र के साथ की जा सकती है, लेकिन टेस्टिंग का लक्ष्य अलग है। लोड टेस्टिंग का लक्ष्य यह निर्धारित करना है कि हमारा एप्लिकेशन निर्दिष्ट संख्या में उपयोगकर्ताओं के साथ काम करता है या नहीं, जबकि स्ट्रेस टेस्टिंग यह निर्धारित करने के लिए आयोजित की जाती है कि लोड सीमा पार होने के बाद एप्लिकेशन कैसे व्यवहार करता है और विफलता को कैसे संभालता है।
रैंप-अप अवधि के आधार पर, प्रदर्शन टेस्टिंग को या तो स्पाइक टेस्ट या सोक टेस्ट के रूप में वर्गीकृत किया जा सकता है। कम समय में उपयोगकर्ताओं में अचानक वृद्धि एक स्पाइक टेस्ट है, और लंबी अवधि में उपयोगकर्ताओं की धीमी वृद्धि एक सोक टेस्ट है।
प्रदर्शन टेस्टिंग क्यों महत्वपूर्ण है?
रेल्स प्रोजेक्ट्स में से एक पर, हम निकट भविष्य में उपयोगकर्ताओं में बहुत वृद्धि की उम्मीद कर रहे थे। हम यह सुनिश्चित करना चाहते थे कि एप्लिकेशन अपेक्षा के अनुरूप प्रदर्शन करे, और बढ़े हुए उपयोगकर्ताओं के साथ महत्वपूर्ण कार्यक्षमता खो न जाए। तो, हम इसे कैसे सुनिश्चित करते हैं? हमने एक लोड टेस्ट किया और जांचा कि क्या एप्लिकेशन उपयोगकर्ताओं में दी गई वृद्धि को संभाल सकता है। प्रदर्शन टेस्टिंग कई अन्य मामलों में महत्वपूर्ण हो सकती है:
- यदि किसी विशिष्ट दिन, जैसे ब्लैक फ्राइडे, पर एप्लिकेशन में उपयोगकर्ताओं में स्पाइक की उम्मीद है, तो संक्षिप्त रैंप-अप अवधि के साथ एप्लिकेशन को स्पाइक टेस्ट करने से सिस्टम में संभावित समस्याओं को खोजने में मदद मिल सकती है।
- लोड टेस्टिंग सिस्टम में उन बग्स की पहचान करने में मदद करती है जो केवल कुछ उपयोगकर्ताओं द्वारा उपयोग किए जाने पर दिखाई नहीं देते या बहुत कम होते हैं।
- यह हमें मूल्यांकन करने की अनुमति देता है कि बढ़े हुए लोड से प्लेटफ़ॉर्म की गति कैसे प्रभावित होती है। यदि एप्लिकेशन धीमा है, तो हम ग्राहकों को खो सकते हैं।
- यह आकलन करने में मदद करता है कि हमारा सिस्टम बढ़े हुए लोड के तहत कैसे काम करता है और क्या 10,000 उपयोगकर्ताओं के होने पर सिस्टम उच्च CPU या मेमोरी उपयोग के साथ क्रैश होता है।
- किसी विशिष्ट संख्या में उपयोगकर्ताओं के लिए एप्लिकेशन चलाने की लागत लोड टेस्टिंग के साथ निर्धारित की जा सकती है।
हम लोड टेस्ट करते समय अपने रेल्स ऐप में एक बग खोजने में सक्षम थे। मैं एक समान परिदृश्य का वर्णन करूंगा जहां हमने एक समस्या की पहचान की। एक होटल बुकिंग ऐप में एक खुली बुकिंग प्रक्रिया थी, और जब केवल कुछ उपयोगकर्ता कमरा बुक करने का प्रयास कर रहे थे, तो सब कुछ ठीक था। हालांकि, जब कई उपयोगकर्ता उसी कमरे को बुक करने का प्रयास कर रहे थे, तो दो अलग-अलग उपयोगकर्ता इसे सफलतापूर्वक बुक करने में सक्षम थे। अपने ऐप को लोड टेस्ट करके, हम समस्या की पहचान करने और फीचर जारी करने से पहले प्रारंभिक चरण में इसे ठीक करने में सक्षम थे।
Apache JMeter का उपयोग करके Rails ऐप को लोड टेस्ट करना
JMeter एक Apache 2.0-लाइसेंस प्राप्त ओपन-सोर्स लोड टेस्टिंग टूल है। यह थ्रेड-आधारित लोड टेस्टिंग प्रदान करता है। थ्रेड-आधारित टेस्टिंग के साथ, हम आसानी से उस तनाव का अनुकरण कर सकते हैं जो हमारे सिस्टम पर होगा जब बहुत सारे उपयोगकर्ता हमारे एप्लिकेशन का एक साथ उपयोग करते हैं। JMeter टेस्ट परिणामों की अच्छी रिपोर्टिंग भी प्रदान करता है।
हम देखेंगे कि कैसे हम Apache JMeter का उपयोग करके संभावित समस्याओं की पहचान करने और हमारे एप्लिकेशन की प्रतिक्रिया समय का पता लगाने के लिए लोड टेस्ट कर सकते हैं, बहुत सारे उपयोगकर्ताओं द्वारा हमारे सिस्टम का उपयोग करने का अनुकरण करके।
JMeter को निम्न लिंक से डाउनलोड किया जा सकता है: https://jmeter.apache.org/download_jmeter.cgi#binaries
कुछ JMeter टर्मिनोलॉजी जिनसे परिचित होना चाहिए
- टेस्ट प्लान टेस्ट प्लान शीर्ष-स्तरीय चीज है जिसके अंदर हम लोड टेस्टिंग घटकों को परिभाषित करते हैं। ग्लोबल कॉन्फिग्स और वेरिएबल्स यहां परिभाषित किए जाते हैं।
- थ्रेड ग्रुप थ्रेड्स और कॉन्फिग्स को परिभाषित करने के लिए उपयोग किया जाता है, जैसे थ्रेड्स की संख्या, रैंप-अप पीरियड्स, थ्रेड्स के बीच देरी, और लूप्स। इसे उन समानांतर उपयोगकर्ताओं की संख्या के रूप में माना जा सकता है जिनके साथ आप लोड टेस्ट चलाना चाहते हैं।
- सैम्पलर वह है जो एक सिंगल थ्रेड निष्पादित करता है। विभिन्न प्रकार के सैम्पलर्स हैं, जैसे HTTP अनुरोध, SMTP अनुरोध, या TCP अनुरोध।
- प्री/पोस्ट प्रोसेसर सैम्पलर चलने से पहले या बाद में कुछ निष्पादित करने के लिए उपयोग किया जाता है। पोस्ट-प्रोसेसर्स एक API कॉल से प्रतिक्रिया डेटा ले सकते हैं और इसे अगले पर उपयोग के लिए पास कर सकते हैं।
- लिसनर सैम्पलर से प्रतिक्रिया सुनता है और प्रत्येक थ्रेड से प्रतिक्रिया समय या प्रतिक्रिया की समग्र रिपोर्ट प्रदान करता है।
- असर्शन यह मान्य करने के लिए उपयोगी हो सकता है कि सैम्पलर से प्रतिक्रिया डेटा वही है जिसकी हम उम्मीद करते थे।
- कॉन्फिग एलिमेंट कॉन्फिगरेशन को परिभाषित करता है, जैसे HTTP हेडर, HTTP कुकीज, या CSV डेटासेट कॉन्फिगरेशन।
लोड टेस्ट चलाने के लिए, हमें पहले एक JMX फाइल बनाने की आवश्यकता है जहां हम उपरोक्त वर्णित JMeter टर्मिनोलॉजी को परिभाषित करते हैं।
लोड टेस्ट के लिए JMX फाइल तैयार करना
JMX एक JMeter प्रोजेक्ट फाइल है जिसे XML फॉर्मेट में लिखा जाता है। JMX फाइल को मैन्युअल रूप से लिखना कठिन हो सकता है, इसलिए हम फाइल बनाने के लिए JMeter इंटरफ़ेस का उपयोग करेंगे।
JMeter इंटरफ़ेस खोलें और टेस्ट प्लान का पता लगाएं। टेस्ट प्लान के अंदर, हम थ्रेड्स और इसकी लोड टेस्ट कॉन्फिगरेशन जोड़ेंगे।
टेस्ट प्लान बनाने के लिए JMeter इंटरफ़ेस
टेस्ट प्लान का नाम बदल सकते हैं कि हम किसके लिए लोड टेस्ट कर रहे हैं। हम थ्रेड ग्रुप (उपयोगकर्ता) को कॉन्फिगर कर सकते हैं। आप यहां डिफ़ॉल्ट सेटिंग्स रख सकते हैं और थ्रेड ग्रुप बनाने के लिए आगे बढ़ सकते हैं।
Add -> Threads(Users) -> Thread Group
थ्रेड ग्रुप में, डिफ़ॉल्ट रूप से एक सिंगल थ्रेड निर्दिष्ट होगा। ऐप तक पहुंचने वाले उपयोगकर्ताओं की संख्या का अनुकरण करने के लिए संख्या को आवश्यकतानुसार बदलें।
चूंकि हम एक वेब-आधारित रेल्स ऐप को लोड टेस्ट करेंगे, हम एक HTTP सैम्पलर जोड़ेंगे। हम एक सैम्पलर जोड़ सकते हैं, जो एक ThreadGroup के अंदर होगा। निम्न को नेविगेट करके HTTP Sampler जोड़ें:
Add -> Sampler -> HTTP Request
यहां, हम उस IP या डोमेन को कॉन्फिगर करते हैं जिस पर हम लोड टेस्ट कर रहे हैं और HTTP मेथड और HTTP एंडपॉइंट के लिए आवश्यक कोई अनुरोध बॉडी।
अंत में, लोड टेस्ट की रिपोर्ट देखने के लिए, हम थ्रेड ग्रुप में एक लिसनर जोड़ सकते हैं।
Add -> Listener -> View Result Tree
व्यू रिजल्ट ट्री प्रत्येक थ्रेड का प्रतिक्रिया समय प्रदर्शित करेगा। हम यहां अन्य प्रकार की रिपोर्ट भी जोड़ सकते हैं। 'व्यू रिजल्ट ट्री' का उपयोग केवल डिबगिंग उद्देश्यों के लिए किया जाना चाहिए और वास्तविक टेस्टिंग के लिए नहीं।
इस तरह, हम एक सरल टेस्ट प्लान बना सकते हैं और इसे निष्पादित कर सकते हैं। JMeter के शीर्ष बार में प्ले आइकन को दबाकर टेस्ट निष्पादित करें।
Rails ऐप को लोड टेस्ट करने से पहले विचार करने योग्य बातें
ऊपर दिया गया उदाहरण एक बहुत ही सरल, सिंगल एंडपॉइंट HTTP अनुरोध है। हमारे रेल्स ऐप के मामले में, हम जिन एंडपॉइंट्स को टेस्ट करना चाहते हैं वे ऑथेंटिकेशन के साथ लॉक हैं। इसलिए, हमें यह सुनिश्चित करने की आवश्यकता है कि निम्नलिखित चीजें मौजूद हैं:
- वेब कुकी - HTTP एंडपॉइंट्स में लोड टेस्ट करने से पहले कुकी हेडर होना चाहिए। JMeter एक बार उपयोगकर्ता लॉग इन होने के बाद कुकी जोड़ने की कार्यक्षमता प्रदान करता है। अगले भाग में, हम देखेंगे कि कैसे हम ब्राउज़र अनुरोध को रिकॉर्ड कर सकते हैं और इसे अपने लोड टेस्ट के लिए JMX फाइल में बदल सकते हैं। हम कुकी रिकॉर्डिंग को भी कवर करेंगे।
- Rails CSRF टोकन - रेल्स CSRF टोकन प्रदान करके ऐप को सुरक्षा भेद्यता से बचाता है, इसलिए हमें यह सुनिश्चित करने की आवश्यकता है कि लोड टेस्ट करने से पहले हमारे अनुरोध में हेडर में CSRF ऑथेंटिकेशन हो। यह CSRF टोकन HTML में
metaटैग के अंदरheaderमें मौजूद होता है।
Rails CSRF Token को JMeter में पोस्ट-प्रोसेसर का उपयोग करके प्राप्त किया जा सकता है। उस HTTP अनुरोध पर राइट-क्लिक करें जो CSRF टोकन वाले वेब पेज को लोड करता है, और फिर Add -> Post Processor -> Regular Expression Extractor चुनें। यहां, आप हेडर मेटा टैग से CSRF मान पढ़ने के लिए निम्नलिखित रेगुलर एक्सप्रेशन एक्सट्रैक्टर कॉन्फिग्स जोड़ सकते हैं:
रेफरेंस नाम:
csrf_valueरेगुलर एक्सप्रेशन:
name="csrfToken" content="(.+?)"टेम्पलेट:
$1$मैच नंबर:
1
अब, वेरिएबल csrf_value का उपयोग अनुरोध बनाने के लिए किया जा सकता है।
ब्राउज़र से अनुरोध रिकॉर्ड करके JMX फाइल बनाना
कम HTTP एंडपॉइंट्स के साथ, JMeter इंटरफ़ेस से JMX फाइल बनाना सरल हो सकता है। हालांकि, बड़े टेस्ट केस के लिए, यह कठिन हो सकता है। साथ ही, एक मौका है कि हम वास्तविक अनुरोधों को याद कर सकते हैं जो एक उपयोगकर्ता एप्लिकेशन का उपयोग करते समय करता है। हम चाहते हैं कि ब्राउज़र से किए गए वास्तविक अनुरोध रिकॉर्ड हों और JMX फाइल स्वचालित रूप से बने।
JMeter को रेल्स ऐप और ब्राउज़र के बीच प्रॉक्सी के रूप में जोड़ा जा सकता है। इसके साथ, सभी अनुरोध JMeter द्वारा रेल्स सर्वर को फॉरवर्ड किए जाएंगे। इसे MITM (मैन इन द मिडिल) अटैक भी कहा जाता है।
JMeter रिकॉर्डिंग
JMeter में रिकॉर्डिंग बनाने के लिए, file -> templates -> recording पर जाएं और क्रिएट पर क्लिक करें। उस होस्टनेम को निर्दिष्ट करें जिसे आप रिकॉर्ड कर रहे हैं। यह आपके लिए स्वचालित रूप से कुछ चीजें उत्पन्न करेगा, जिसमें कुकी मैनेजर शामिल है। कुकी मैनेजर ऑथेंटिकेशन के लिए आवश्यक कुकी को सेव करेगा।
JMeter SSL सर्टिफिकेट के साथ HTTPS अनुरोध सत्यापित करना
ब्राउज़र से किया गया यह अनुरोध JMeter को फॉरवर्ड किया जाएगा, और JMeter इसे वेब सर्विस को फॉरवर्ड करेगा और अनुरोधों को रिकॉर्ड करेगा ताकि हम JMeter रिकॉर्डिंग से लोड टेस्ट चला सकें। यदि एप्लिकेशन को SSL कनेक्शन के लिए HTTPS प्रोटोकॉल की आवश्यकता है, तो ब्राउज़र में एक सर्टिफिकेट जोड़ने की आवश्यकता है। सर्टिफिकेट जोड़ने के लिए, Firefox या कोई अन्य ब्राउज़र खोलें। Firefox में, settings > Privacy > Manage certificate पर जाएं और JMeter सर्टिफिकेट जोड़ें ताकि ब्राउज़र JMeter द्वारा उत्पन्न सर्टिफिकेट को पहचान सके।
cmd + sht + g दर्ज करें और पथ /usr/local/Cellar/jmeter/5.2/libexec/bin/jmeter दर्ज करें सर्टिफिकेट जोड़ने के लिए
Firefox को JMeter को प्रॉक्सी के रूप में उपयोग करने के लिए कॉन्फिगर करना
अगला, हमें Firefox से अनुरोध को हमारे JMeter रिकॉर्डिंग स्क्रिप्ट पर फॉरवर्ड करने की आवश्यकता है। यह Firefox में प्रॉक्सी कॉन्फिगर करके किया जा सकता है। Firefox खोलें और Preferences -> Advanced -> Connection(settings) पर जाएं। यहां, HTTP प्रॉक्सी को "localhost" और पोर्ट को "8080" पर सेट करें और "Use this proxy server for all protocols" चेक करें।
अब, हम JMeter पर जा सकते हैं और पहले चुने गए टेम्पलेट से Script recording सेक्शन पर जा सकते हैं। एक बार जब हम स्टार्ट बटन दबाते हैं, तो JMeter इनकमिंग अनुरोधों को स्वीकार करना शुरू कर देता है। जब हम Firefox पर जाते हैं और उस एप्लिकेशन को ब्राउज़ करते हैं जिसे हम लोड टेस्ट कर रहे हैं, तो यह रिकॉर्ड करेगा और इसे JMX फाइल में बदल देगा, जिसे हम लोड टेस्टिंग के लिए चला सकते हैं।
JMeter के साथ वितरित लोड टेस्टिंग
टेस्ट चलाते समय, हम अपनी स्थानीय मशीनों में से एक से टेस्ट कर सकते हैं। टेस्ट प्लान तैयार करते समय यह ठीक है, लेकिन वास्तविक टेस्ट चलाते समय, हमें इसे बदलने की आवश्यकता है। एक मशीन पर लोड टेस्ट करने से हार्डवेयर सीमाएं होंगी (यानी CPU और मेमोरी) और अनुरोध स्थान सीमाएं। ये टेस्ट वास्तविक उपयोगकर्ताओं द्वारा एप्लिकेशन का उपयोग करने के ट्रैफिक का अनुकरण करने के लिए चलाए जाते हैं। इस उद्देश्य के लिए, हमें टेस्ट को विभिन्न सर्वरों पर वितरित करने और सभी परिणामों को देखने के लिए एक ही स्थान की आवश्यकता है।
JMeter टेस्ट को ऑर्केस्ट्रेट करने के लिए एक प्राइमरी नोड और टेस्ट चलाने के लिए कई सेकेंडरी नोड्स प्रदान करता है। यह वास्तविक उपयोगकर्ताओं द्वारा एप्लिकेशन का उपयोग करने का अनुकरण करने में मदद करता है। हम टेस्टिंग सर्वरों को अपने वास्तविक उपयोगकर्ताओं के करीब विभिन्न क्षेत्रों में वितरित कर सकते हैं।
JMeter वितरित टेस्टिंग
वितरित टेस्ट करने के लिए, प्राइमरी और सेकेंडरी दोनों सर्वरों पर JMeter इंस्टॉल करके शुरू करें।
सेकेंडरी सर्वर पर करने योग्य चीजें:
jmeter/binपर जाएं औरjmeter-serverकमांड निष्पादित करें। यह टेस्ट निष्पादित करने के लिए सर्वर शुरू करेगा।- यदि टेस्ट के लिए किसी CSV इनपुट की आवश्यकता है, तो इन फाइलों को इस सर्वर पर जोड़ें।
प्राइमरी सर्वर पर करने योग्य चीजें:
- jmeter/bin डायरेक्टरी पर जाएं और
jmeter.propertiesफाइल खोलें। remote_hostsवाली लाइन को संपादित करें और सेकेंडरी सर्वरों के IPs को कॉमा से अलग करके जोड़ेंremote_hosts=<s1_ip>,<s2_ip>।- JMeter टेस्ट चलाएं।
सेकेंडरी सर्वर वास्तविक टेस्ट चलाने के लिए जिम्मेदार होगा, और प्राइमरी सर्वर रिपोर्ट्स को एकत्रित करेगा।
लोड टेस्टिंग करने के लिए, हमें हमेशा UI से टेस्ट ट्रिगर करने के बजाय CLI कमांड का उपयोग करना चाहिए, क्योंकि इससे लोड टेस्टिंग सर्वरों के लिए प्रदर्शन समस्याएं हो सकती हैं। हम JMX फाइलनाम निर्दिष्ट करते हुए JMeter कमांड का उपयोग कर सकते हैं:
> jmeter -n -t path/to/test.jxm -r
या
> jmeter -n -t path/to/test.jxm -R s1_ip,s2_ip,…
-r jmeter.properties में निर्दिष्ट रिमोट सर्वर का उपयोग करता है
-n इसे GUI मोड के बिना चलाएगा
-t jmx फाइल का पथ
हमने अपने रेल्स सर्वर के लिए Puma बनाम Unicorn पर कैसे निर्णय लिया
Puma और Unicorn रेल्स के लिए दो अलग-अलग वेब सर्वर हैं। दोनों के लाभ हैं, तो हम कैसे तय करते हैं कि कौन सा सर्वश्रेष्ठ है? यह एप्लिकेशन पर निर्भर करता है। कुछ एप्लिकेशन Unicorn के साथ सबसे अच्छा काम करते हैं, और कुछ Puma के साथ सबसे अच्छा काम करते हैं। हमें अपने एक रेल्स ऐप के लिए Unicorn और Puma के बीच चयन करना था, और हमने लोड टेस्टिंग से प्राप्त डेटा के आधार पर ऐसा किया। हमने एक बार Unicorn के साथ रेल्स ऐप पर लोड टेस्ट किया और दूसरी बार Puma का उपयोग करके। केवल एक चीज जो हमने बदली वह थी रेल्स ऐप पर वेब सर्वर।
हमें इस टेस्ट से निम्नलिखित परिणाम मिला: 
Puma और Unicorn के बीच प्रतिक्रिया समय का अंतर
हमने पाया कि जब प्लेटफ़ॉर्म पर बड़ी संख्या में उपयोगकर्ता होते हैं तो Puma हमारे रेल्स ऐप के लिए बेहतर प्रदर्शन करता है। इसका मतलब है कि हम कम संख्या में एप्लिकेशन सर्वरों के साथ अधिक उपयोगकर्ताओं को संभाल पाएंगे।
नोट: यह आपके द्वारा उपयोग किए जा रहे सर्वर इंस्टेंस के प्रकार और ऐप द्वारा किए जाने वाले बिजनेस लॉजिक प्रोसेसिंग के प्रकार पर निर्भर करता है।
रेल्स ऐप को स्ट्रेस करते समय सामने आई कुछ सामान्य विफलताएं और उन्हें कैसे ठीक करें
- अनऑप्टिमाइज़्ड डेटाबेस क्वेरी
- N+1 क्वेरी समस्या को खत्म करें।
- एक्सेस पैटर्न के अनुसार इंडेक्स जोड़ें।
- डेटाबेस के सामने रेडिस जैसी कैशिंग लेयर का उपयोग करें।
- धीमी Ruby कोड प्रदर्शन
- कोड को ऑप्टिमाइज़ करने के लिए मेमोइज़ेशन का उपयोग करें।
- O(n²) जटिलता का पता लगाएं और इष्टतम एल्गोरिदम का उपयोग करें।
- माइक्रोसर्विस आर्किटेक्चर में, सेवाओं के बीच बहुत सारे HTTP कॉल हो सकते हैं। नेटवर्क कॉल धीमे हैं।
- माइक्रोसर्विसेज के लिए मैसेजिंग सिस्टम का उपयोग करके HTTP कॉल की संख्या कम करें।
- समवर्ती रूप से बनाए जाने पर वही रिकॉर्ड दो बार बनाया जाता है।
- डेटाबेस यूनिक कंस्ट्रेंट जोड़ें।
- FIFO इवेंट (क्यू)-आधारित संसाधन निर्माण का उपयोग करें।
- जब भी संभव हो बैकग्राउंड प्रोसेसिंग का उपयोग करें, जैसे Sidekiq।
- API प्रतिक्रिया समय के लिए SLA परिभाषित करें और प्रदर्शन टेस्टिंग को विकास जीवनचक्र के हिस्से के रूप में शामिल करें।
लोड टेस्टिंग करने के लिए किस एनवायरनमेंट का उपयोग करना चाहिए?
उत्पादन वातावरण में लोड टेस्ट करना आदर्श विकल्प नहीं है क्योंकि यह उत्पादन में समस्याएं और यहां तक कि डाउनटाइम पैदा कर सकता है। हम उत्पादन वातावरण में समस्याएं पैदा नहीं करना चाहते, लेकिन हम फिर भी यह सुनिश्चित करना चाहते हैं कि टेस्ट रिपोर्ट वास्तविक डेटा को दर्शाती है, उत्पादन के समान। लोड/स्ट्रेस टेस्ट के लिए, उत्पादन का एक रेप्लिका वातावरण बनाने की सिफारिश की जाती है। इसमें निम्न जैसी चीजें शामिल हैं:
- एप्लिकेशन सर्वरों की संख्या।
- डेटाबेस सर्वर के हार्डवेयर स्पेसिफिकेशन, रेप्लिकास सहित।
- टेस्टिंग डेटाबेस में उत्पादन-जैसा डेटा। इसमें उत्पादन में आने वाले लगभग समान डेटा वॉल्यूम शामिल होना चाहिए।
उत्पादन-जैसा वातावरण बनाना चुनौतीपूर्ण और महंगा हो सकता है। इसलिए, हम क्या लोड टेस्ट कर रहे हैं, इसके आधार पर केवल उन घटकों को छूने वाले इंफ्रास्ट्रक्चर को उत्पादन-जैसा अपग्रेड किया जा सकता है। यह लागत बचाता है। हर तीन महीने में एक बार अपने ऐप को लोड/स्ट्रेस टेस्ट करना बेहतर है। हालांकि, एकल उपयोगकर्ता के साथ प्रदर्शन टेस्टिंग और यह मान्य करना कि प्रतिक्रिया समय परिभाषित मानक (कुछ ऐसा जैसे 200ms) के तहत है, ऐसा कुछ है जिसे हमें विकास चक्र में जोड़ने की आवश्यकता है।
लोड टेस्टिंग के दौरान, हमें टारगेट सर्वर के CPU/मेमोरी उपयोग जैसे डेटा पॉइंट्स की भी आवश्यकता होती है। मेमोरी/CPU उपयोग में स्पाइक एप्लिकेशन को क्रैश कर सकता है। हार्डवेयर KPIs को मापने के लिए, लोड टेस्ट शुरू करने से पहले Prometheus जैसे मॉनिटरिंग टूल्स जोड़ें।
Apache JMeter लोड टेस्टिंग के लिए एक शक्तिशाली टूल है। हमने Apache JMeter का उपयोग रेल्स ऐप्स को लोड टेस्ट करने के लिए किया, लेकिन इसका उपयोग किसी भी स्टैक पर बने एप्लिकेशन के लोड/स्ट्रेस टेस्टिंग के लिए किया जा सकता है। लोड टेस्टिंग एप्लिकेशन में डेटा-संचालित निर्णय लेने में मदद करती है। लोड टेस्टिंग डरावनी लग सकती है, लेकिन शुरुआत में थोड़े निवेश के साथ, यह लंबी अवधि में एप्लिकेशन में बहुत स्थिरता और विश्वसनीयता जोड़ सकती है।
