जेमीटर - स्विस परीक्षक चाकू (भाग 1)

JMeter के बारे में बात करें? सबसे अधिक संभावना है, यदि आप विषय में हैं, तो आप पहले से ही तनाव परीक्षण के लिए इस उपकरण के बारे में सब कुछ पढ़ चुके हैं। लेकिन मेरे पास आपको आश्चर्यचकित करने के लिए कुछ है। क्यूए में तीन साल के लिए, मैंने महसूस किया कि जेमीटर बहुत बहुमुखी है और इसका उपयोग विभिन्न उद्देश्यों के लिए किया जा सकता है। उदाहरण के लिए, इसके लिए:

• कुछ उपयोगकर्ताओं के लिए साइट के पतन के साथ एक मायावी बग की खोज;
• हजारों उत्पाद पृष्ठों पर त्वरित कैश वार्मिंग;
• मोबाइल एप्लिकेशन के बैकएंड का परीक्षण करना;
• थोड़े समय में एप्लिकेशन डेटाबेस में उपयोगकर्ता डेटा के साथ 2000 रिकॉर्ड बना रहा है।

यदि आप रुचि रखते हैं, तो बिल्ली में आपका स्वागत है। यह स्वेच्छा से निकला, इसलिए मैं लेख को दो भागों में तोड़ दूंगा।

अस्वीकरण: स्पष्ट कारणों के लिए, मैं वास्तविक परियोजनाओं से स्क्रीनशॉट को लेख में सम्मिलित नहीं करता (या उनसे सभी महत्वपूर्ण जानकारी निकालता हूं)। केवल अनुसंधान और शैक्षिक उद्देश्यों के लिए चित्र प्रदान किए जाते हैं।

क्लासिक JMeter आवेदन

JMeter - GUI के साथ जावा एप्लेट। परीक्षण के लिए, यह बिना ग्राफ़िकल इंटरफ़ेस के शुरू होता है। और परीक्षण स्क्रिप्ट लिखने के लिए, उसके पास एक पैनल है जिसमें आप कुछ भी कर सकते हैं।

इस तरह से स्क्रिप्ट बनाने की प्रक्रिया दिखती है (यहाँ "शब्द" भी फिट नहीं बैठता है)

एक सामान्य परीक्षण योजना बनाई जाती है, जिसमें थ्रेड समूह खुद को परीक्षण के मुख्य तत्वों के साथ फेंकता है: प्रक्रिया नियंत्रक और अनुरोध (HTTP, FTP, आदि)।

इसके अलावा, पैरामीटर सेट करने के लिए अतिरिक्त तत्व हैं। उदाहरण के लिए, HTTP रिक्वेस्ट डिफॉल्ट्स आपको मुख्य सर्वर, हेडर निर्दिष्ट करने और अतिरिक्त संपत्ति (चित्र, शैली, फ़ॉन्ट, आदि) के डाउनलोड को सक्षम / अक्षम करने की अनुमति देता है। यह पता लगाना आसान है। और आप तुरंत इस इंटरफ़ेस से एक परीक्षण चला सकते हैं और परिणाम देख सकते हैं।

JMeter ऐसे परीक्षण मामलों को रिकॉर्ड कर सकता है। यह स्थानीय मशीन पर एक प्रॉक्सी के रूप में चलता है और, यदि आप किसी ब्राउज़र (या एप्लिकेशन) को कॉन्फ़िगर करते हैं, तो इस प्रॉक्सी के माध्यम से ट्रैफ़िक को ड्राइव करें, JMeter सभी अनुरोधों और प्रतिक्रियाओं को रिकॉर्ड करेगा। और इस सेट से, आप एक परीक्षण स्क्रिप्ट को मनगढ़ंत कर सकते हैं, जो उपयोगकर्ता के कार्यों को दोहराएगा, और जब चाहें और जहां चाहे इसे चला सकता है:



मुख्य समस्या जावा की स्मृति का ही ढेर है। यह छत पर टिकी हुई है और शीर्ष-अंत मशीनों पर भी एक साथ परीक्षण के 50 धागे के साथ गिर सकती है।
यदि पूर्ण लोड परीक्षण के लिए मशीन में पर्याप्त शक्ति नहीं है, तो किसी तृतीय-पक्ष संगठन से संपर्क करें। उन्होंने एक इंफ्रास्ट्रक्चर तैनात किया जो सर्वर का एक सेट है। उन्हें वही JMeter मिला। शुल्क के लिए, ये लोग आपकी स्क्रिप्ट को किसी भी लोड पर चलाएंगे। हमने Octoperf और Blazemeter में ऐसी सेवाओं के लिए आवेदन किया था।

यह फुटबॉल है, बच्चा: हमने आंशिक सर्वर क्रैश के साथ बग को कैसे पकड़ा

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

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

लॉन्च से पहले, हमने एक पूर्ण भार परीक्षण किया और सुनिश्चित किया कि सब कुछ उसी तरह काम करता है जैसे यह होना चाहिए। सर्वर संरचना इस प्रकार दिखती है:

1. क्लाइंट से अनुरोध लोड संतुलन सर्वर → जाता है
2. लोड बैलेंसिंग सर्वर आठ सीडी सर्वर की स्थिति की जाँच करता है →
3. लोड बैलेंसिंग सर्वर कम से कम लोड किए गए सीडी सर्वर के लिए एक अनुरोध भेजता है →
4. CD सर्वर क्लाइंट को प्रतिसाद देता है।

लॉन्च के एक साल बाद, साइट पर उपयोगकर्ताओं की एक बड़ी बाढ़ के दौरान, ग्राहक ने फोन किया और कहा कि साइट नीचे थी:

- हमारी साइट काम नहीं करती है! बिल्कुल काम नहीं करता है! बस एक सफेद स्क्रीन और ब्राउज़र से एक शिलालेख कि साइट नीचे है! - क्लाइंट कहता है।
हम साइट खोलने की दहशत में हैं, और इसके साथ सब कुछ ठीक है:
"यह अभी भी काम करता है," हम जवाब देते हैं।
क्लाइंट फोन और कंप्यूटर से साइट खोलता है और ... सब कुछ ठीक भी है!
- सच, सॉरी। जाहिर है, उपयोगकर्ताओं को समस्या है।

इस तरह के संदेश खरोंच से प्रकट नहीं होते हैं, इसलिए हमने एक अध्ययन किया: हमने सर्वर घनत्व सर्वर की स्थिति की निगरानी के लिए एक उपयोगिता लॉन्च की और साइट पर उपयोगकर्ताओं की आमद के दौरान उनके साथ क्या हुआ, इस पर ध्यान दिया:


एक लोड है, लेकिन सभी सीडी-सर्वर उसी के बारे में और यहां तक ​​कि देखते हैं

जल्द ही कहानी खुद को दोहराया - कुछ उपयोगकर्ताओं ने पूरी तरह से टूटी हुई साइट की सूचना दी। यह किसी प्रकार की त्रुटि नहीं थी या पृष्ठ नहीं मिला - सर्वर ने केवल अनुरोध का जवाब नहीं दिया। JMeter की सहायता से स्थिति को पकड़ना संभव था।

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



हमने उन्हीं संपत्तियों को डाउनलोड किया जो पहले ही सौ बार कैश की जा चुकी थीं। इसलिए, भार नगण्य निकला। फिर विचार आया: साइट पर - एक गाड़ी और कुछ तारीखों के लिए समाचार के साथ पृष्ठों की एक छोटी गाड़ी। यदि आप कुछ चरों को आगे बढ़ाते हैं और URL में स्थानापन्न करते हैं, तो हमें हमेशा एक यादृच्छिक पृष्ठ मिलेगा (उदाहरण के लिए - ... url / news / 2016/08/23 / पृष्ठ? = 4)।

अचानक, हमने महसूस किया कि सर्वर घनत्व में पिछले कुछ समय में सर्वर लोड के ग्राफ में कुछ "स्मूथिंग" है। यदि पांच मिनट में सर्वर पर लोड 100% तक पहुंच गया, तो 0% तक गिर गया, और 20-30 सेकंड के बाद 90% तक बढ़ गया, यह इस अवधि के लिए औसत मूल्य दिखाएगा - लगभग 80-90%। इसलिए, हमने एक वास्तविक सर्वर क्रैश नहीं देखा।

तनाव परीक्षणों के दौरान लॉग में विस्तार से जांच करने के बाद, हमें पता चला कि सीडी-सर्वरों में से एक 100% लोड पर रिबूट में चला गया और उसने किसी को इसके बारे में नहीं बताया (वह इस तरह के एक अंतर्मुखी है)।



लोड बैलेंसर केवल सभी सर्वरों के सीपीयू उपयोग पर ध्यान देता था। उन्होंने देखा कि उनमें से एक को 20% पर लोड किया गया था, और बाकी को 90% पर लोड किया गया था, और उपयोगकर्ता को पहले भेजा। और वह रिबूट में था और एक सफेद स्क्रीन दिया। इसके अलावा, वितरण सर्वर ने उपयोगकर्ता को एक कुकी से अवगत कराया और इसे निष्क्रिय सर्वर से कसकर बांध दिया। इसलिए, अद्यतन के बाद भी, साइट अनुपलब्ध थी। शेष 8 में से 7 उपयोगकर्ताओं ने एक ही समय में जीवन का आनंद लिया और कहा कि सब कुछ काम करता है।

निष्कर्ष:

हमने पाया कि JMeter का उपयोग तनाव परीक्षण के लिए किया जा सकता है और साथ ही अन्य उपकरणों के साथ परीक्षण के दौरान सर्वर की स्थिति का विश्लेषण किया जा सकता है। हम कुछ उपयोगकर्ताओं के बीच साइट के गिरने के साथ समस्या को "पकड़ने" में कामयाब रहे और लोड संतुलन तर्क को सही करके और राज्य नियंत्रण को जोड़कर इसे हल किया।

अगले भाग में मैं आपको बताता हूँ कि कैसे, JMeter की सहायता से, हमने उत्पाद पृष्ठों के लिए कैशिंग प्रक्रिया की स्थापना की, बिना एप्लिकेशन के ही मोबाइल एप्लिकेशन के संचालन का परीक्षण किया और डेटाबेस तक पहुँच के बिना सिस्टम में 2000 उपयोगकर्ता बनाए।