विश्वसनीय तनाव अप्रत्याशित बारीकियों को ध्यान में रखते हुए

हमने एक साल पहले बड़े लोड परीक्षणों के बुनियादी ढांचे के निर्माण के बारे में सोचा था, जब हम एक ही समय में हमारी सेवा में काम करने वाले 12K ऑनलाइन उपयोगकर्ताओं के निशान तक पहुंच गए थे। 3 महीने के लिए हमने परीक्षण का पहला संस्करण बनाया, जिसने सेवा की सीमाएं दिखाईं।

भाग्य की विडंबना यह है कि जिस समय परीक्षण शुरू किया गया था, उसी समय हम ठेस पर पहुंच गए थे, जिसके परिणामस्वरूप यह सेवा 2 घंटे गिर गई। इसके अतिरिक्त इसने हमें एक प्रभावी भार वहन करने वाली अवसंरचना बनाने के लिए मामले से लेकर परीक्षणों का संचालन शुरू करने के लिए प्रोत्साहित किया। बुनियादी ढांचे से मेरा मतलब है कि लोड के साथ काम करने के लिए सभी उपकरण: लॉन्च करने और स्टार्टअप के लिए उपकरण, लोड को लोड करने के लिए एक क्लस्टर, एक क्लस्टर, एक समान उत्पाद, मैट्रिक्स इकट्ठा करने के लिए सेवाएं और रिपोर्ट तैयार करने के लिए, यह सब प्रबंधित करने के लिए कोड और स्केलिंग के लिए सेवाएं।



यह कैसे सरल है miro.com योजना लग रहा है: कई अलग-अलग सर्वर हैं जो किसी तरह एक दूसरे के साथ बातचीत करते हैं, और प्रत्येक एक विशिष्ट कार्य करता है। ऐसा लगता है कि लोड परीक्षणों के बुनियादी ढांचे के निर्माण के लिए, हमारे लिए इस तरह की योजना तैयार करना, सभी रिश्तों को ध्यान में रखना और प्रत्येक ब्लॉक को क्रमिक रूप से स्क्रिप्ट के साथ कवर करना शुरू करना पर्याप्त था। यह दृष्टिकोण अच्छा है, लेकिन इसमें कई महीने लगेंगे, जो कि तेजी से विकास के कारण हमारे लिए उपयुक्त नहीं था - पिछले छह महीनों में हम 12K से 20K तक ऑनलाइन हो गए हैं जो एक ही समय में सेवा में काम कर रहे ऑनलाइन उपयोगकर्ता हैं। इसके अलावा, हमें नहीं पता था कि हमारी सेवा का बुनियादी ढांचा भार में वृद्धि का जवाब कैसे देगा: कौन से ब्लॉक एक अड़चन बन जाएंगे, और किसको हम रैखिक रूप से माप सकते हैं।

नतीजतन, हमने वर्चुअल उपयोगकर्ताओं का उपयोग करके सेवा का परीक्षण करने का फैसला किया, उनके यथार्थवादी काम का अनुकरण करते हुए, अर्थात्, एक उत्पादन क्लोन का निर्माण किया और एक बड़ा परीक्षण किया, जो:

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

इस तरह के परीक्षण का एकमात्र माइनस इसकी लागत मूल्य है, क्योंकि इसके लिए हमें एक ऐसे वातावरण की आवश्यकता है जो उत्पादन वातावरण से बड़ा होगा।

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

यथार्थवादी परिदृश्य बनाएँ

यथार्थवादी परिदृश्य बनाने के लिए, हमें चाहिए:

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

अब प्रत्येक आइटम के बारे में अधिक।

उत्पादों पर उपयोगकर्ता के काम का विश्लेषण

हमारी सेवा में, उपयोगकर्ता बोर्ड बना सकते हैं और विभिन्न सामग्रियों के साथ उन पर काम कर सकते हैं: फोटो, ग्रंथ, मोकास, स्टिकर, आरेख इत्यादि। पहली मीट्रिक जिसे हमें इकट्ठा करने की आवश्यकता है, वह है बोर्डों की संख्या और उन पर सामग्री का वितरण।


एक ही समय में एक ही बोर्ड पर, कुछ उपयोगकर्ता सक्रिय रूप से कुछ बना सकते हैं - बनाएं, हटाएं, संपादित करें - और कुछ बस बनाई गई सामग्री को देखें। यह भी एक महत्वपूर्ण मीट्रिक है - बोर्ड पर सामग्री को बदलने वाले उपयोगकर्ताओं की संख्या का अनुपात एक बोर्ड के कुल उपयोगकर्ताओं की संख्या। यह हम डेटाबेस के साथ काम करने के आंकड़ों के आधार पर प्राप्त कर सकते हैं।

हमारे बैकेंड में हम घटक दृष्टिकोण का उपयोग करते हैं। घटक जिन्हें हम मॉडल कहते हैं। हम अपने कोड को मॉडल में तोड़ते हैं ताकि व्यापार तर्क के प्रत्येक भाग के लिए एक निश्चित मॉडल जिम्मेदार हो। हम प्रत्येक मॉडल के माध्यम से होने वाली डेटाबेस कॉल की संख्या की गणना कर सकते हैं और समझ सकते हैं कि तर्क का कौन सा हिस्सा डेटाबेस को सबसे अधिक लोड करता है।



सुविधाजनक कस्टम ब्लॉक

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



प्रभावी ढंग से डैशबोर्ड कैसे लोड करें? उत्पादन व्यवहार का विश्लेषण करते समय, हमने एक बड़े खाते के डैशबोर्ड के उद्घाटन के दौरान डेटाबेस में लोड स्पाइक्स को देखा। हम एक समान खाते को फिर से बना सकते हैं और स्क्रिप्ट में इसके डेटा का उपयोग करने की तीव्रता को बदल सकते हैं, प्रभावी रूप से कम संख्या में हिट के साथ डैशबोर्ड लोड कर सकते हैं। हम अधिक यथार्थवाद के लिए एक असमान भार भी बना सकते हैं।

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

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

हमने सेवा के अन्य सभी ब्लॉकों को प्रभावी ढंग से लोड करने के लिए इस तर्क का उपयोग किया। उसी समय, कार्यात्मक का उपयोग करने के तर्क के दृष्टिकोण से प्रत्येक व्यक्तिगत ब्लॉक यथार्थवादी नहीं हो सकता है; यह महत्वपूर्ण है कि यह सर्वरों पर एक यथार्थवादी मीट्रिक लोड देता है। और फिर हम इन ब्लॉकों से एक स्क्रिप्ट बना सकते हैं जो उपयोगकर्ताओं के वास्तविक कार्य की नकल करता है।

डेटा स्क्रिप्ट का हिस्सा है।

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

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

इस भाग के लिए परिणाम

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

लोड क्लस्टर

लोड लागू करने के लिए उपकरणों की योजना:



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

वेब-सॉकेट के अंदर कस्टम काम

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

वेब सॉकेट के अंदर का काम आमतौर पर बहुत कस्टम होता है: आप कुछ डेटा कस्टम के साथ कुछ तरीकों को लागू करते हैं और, तदनुसार, आपको खुद को यह समझने की आवश्यकता है कि क्या अनुरोध सही तरीके से निष्पादित किया गया था और इसे निष्पादित करने में कितना समय लगा। इस प्लगइन के अंदर श्रोता को भी स्वतंत्र रूप से लिखा गया है; हमें एक अच्छा तैयार समाधान नहीं मिला।

तनाव ग्राहक

हम यथासंभव सरल को दोहराना चाहते हैं जो वास्तविक उपयोगकर्ता करते हैं। लेकिन हम यह नहीं जानते कि डब्ल्यूएस के अंदर ब्राउज़र में क्या हो रहा है, इसे कैसे रिकॉर्ड करें और वापस चलाएं। अगर हम खरोंच से WS के अंदर सब कुछ लिखते हैं, तो हमें एक नया क्लाइंट मिलेगा, न कि वास्तविक उपयोगकर्ताओं का उपयोग करने वाला। यदि हमारे पास पहले से ही एक काम है तो मुझे एक नया ग्राहक लिखने का मन नहीं है।

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

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

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

हमारे अमेज़न उदाहरण उदाहरण

 Jmeter server  AWS: m5.large ($0.06 per Hour) vCPU: 2 Mem (GiB): 8 Dedicated EBS Bandwidth (Mbps): Up to 3,500 Network Performance (Gbps): Up to 10 → ~730  

सैकड़ों सर्वर कहां से और कैसे बचाएं

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

हमने Blazemeter और RedLine13 जैसे क्लाउड लोड टूल्स का उपयोग नहीं किया, क्योंकि उनके पास उपयोग प्रतिबंध हैं जो हमारे अनुरूप नहीं थे। हमारे पास अलग-अलग परीक्षण साइटें हैं, इसलिए हम एक सार्वभौमिक समाधान खोजना चाहते थे जो 90% विकास को स्थानीय परीक्षणों में शामिल करने की अनुमति देगा।

परिणामस्वरूप, हमने क्लाउड प्रदाताओं के बीच चयन किया।



हमारा उत्पादन एडब्ल्यूएस पर है, इसलिए हम मुख्य रूप से वहां परीक्षण कर रहे हैं, और हम चाहते हैं कि परीक्षण बेंच उत्पादन के समान हो। अमेज़ॅन में कई भुगतान विशेषताएं हैं, जिनमें से कुछ हम उत्पाद में उपयोग करते हैं, उदाहरण के लिए, बैलेंसर्स। यदि AWS में इन सुविधाओं की आवश्यकता नहीं है, तो आप Hetzner में उन्हें 17 गुना सस्ता उपयोग कर सकते हैं। या आप सर्वर को Hetzner में रख सकते हैं, Openstack का उपयोग कर सकते हैं और स्वयं बैलेंसर और अन्य सुविधाएँ लिख सकते हैं, क्योंकि Openstack का उपयोग करने के बाद आप पूरे बुनियादी ढांचे को दोहरा सकते हैं। हम सफल हुए हैं।

AWS में 69 उदाहरणों के साथ 50K उपयोगकर्ताओं का परीक्षण हमें प्रति माह लगभग $ 3K खर्च होता है। कैसे बचाएं? उदाहरण के लिए, AWS के अस्थायी उदाहरण हैं - स्पॉट इंस्टेंसेस। उनकी शीतलता यह है कि हम उन्हें लगातार नहीं रखते हैं, हम उन्हें केवल परीक्षणों की अवधि के लिए बढ़ाते हैं और उनकी लागत बहुत कम होती है। सूक्ष्मता यह है कि हमारे परीक्षण के समय कोई और व्यक्ति उन्हें अधिक कीमत पर खरीद सकता है। सौभाग्य से, यह पहले कभी नहीं हुआ है, लेकिन हम पहले से ही अपने खर्च पर कम से कम 60% लागत बचाते हैं।

लोड क्लस्टर

हम Jmeter बॉक्स क्लस्टर का उपयोग करते हैं। यह बहुत अच्छा काम करता है, इसे किसी भी तरह से संशोधित करने की आवश्यकता नहीं है। इसके कई लॉन्च विकल्प हैं। हम सबसे सरल का उपयोग करते हैं जब एक विज़ार्ड एन इंस्टेंस शुरू करता है, और उनमें से सैकड़ों हो सकते हैं।



विज़ार्ड Jmeter सर्वर पर स्क्रिप्ट चलाता है, उनके साथ संपर्क में रखते हुए, वास्तविक समय में सभी उदाहरणों से सामान्य आंकड़े एकत्र करता है और इसे कंसोल में प्रदर्शित करता है। यह सब बिल्कुल एक सर्वर पर स्क्रिप्ट चलाने के समान दिखता है, हालांकि हम एक सौ सर्वर पर लॉन्च के परिणाम देखते हैं।

सभी उदाहरणों पर स्क्रिप्ट निष्पादन के परिणामों के विस्तृत विश्लेषण के लिए, हम किबाना का उपयोग करते हैं। फ़ाइलबीम का उपयोग करके पारसीम लॉग।

अपाचे जेमीटर के लिए एक प्रोमेथियस श्रोता

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

वृषभ

हम वृषभ के साथ कई मौजूदा समस्याओं को हल करना चाहते हैं, लेकिन अभी तक इससे निपटा नहीं है:

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

इस भाग के परिणाम

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

अवसंरचना परीक्षणों का उपयोग करने के उदाहरण

उपरोक्त पूरी कहानी मोटे तौर पर एक सेवा सीमा परीक्षण के लिए यथार्थवादी परिदृश्य बनाने के बारे में है। नीचे दिए गए उदाहरण बताते हैं कि आप स्थानीय समस्याओं को हल करने के लिए लोड परीक्षणों के बुनियादी ढांचे का पुन: उपयोग कैसे कर सकते हैं। मैं दो परीक्षणों के बारे में विस्तार से बात करूंगा, लेकिन सामान्य तौर पर हम समय-समय पर लगभग 10 प्रकार के लोड परीक्षणों का संचालन करते हैं।

डेटाबेस परीक्षण

हम डेटाबेस में परीक्षण को क्या लोड कर सकते हैं? भारी क्वेरी की संभावना नहीं है, क्योंकि हम उन्हें एकल-थ्रेडेड मोड में परीक्षण कर सकते हैं, यदि हम केवल क्वेरी योजनाओं को देखते हैं।

एक दिलचस्प स्थिति तब होती है जब हम परीक्षण चलाते हैं और डिस्क पर लोड देखते हैं। ग्राफ दिखाता है कि iowait कैसे उगता है।



आगे हम देखते हैं कि यह उपयोगकर्ताओं को प्रभावित करता है।



हम इसका कारण समझते हैं: वैक्यूम ने काम नहीं किया और डेटाबेस से कचरा डेटा नहीं हटाया। यदि आपने Postgresql के साथ काम नहीं किया है, तो वैक्यूम जावा में कचरा संग्राहक की तरह है।



इसके अलावा, हम देखते हैं कि चेकपॉइंट शेड्यूल से बाहर काम करना शुरू कर दिया। हमारे लिए, यह एक संकेत है कि Postgresql कॉन्फ़िगर डेटाबेस के साथ काम की तीव्रता के अनुरूप नहीं है।



हमारा कार्य डेटाबेस को ठीक से कॉन्फ़िगर करना है ताकि ऐसी स्थितियों की पुनरावृत्ति न हो। एक ही Postgresql में कई सेटिंग्स हैं। ठीक ट्यूनिंग के लिए, आपको लघु पुनरावृत्तियों में काम करने की आवश्यकता है: कॉन्फ़िगर को ठीक किया, लॉन्च किया, चेक किया गया, कॉन्फ़िगर को ठीक किया, लॉन्च किया, चेक किया। बेशक, इसके लिए आपको आधार पर एक अच्छा लोड लागू करने की आवश्यकता है, लेकिन इसके लिए आपको बस बड़े बुनियादी ढांचे के परीक्षणों की आवश्यकता है।

ख़ासियत यह है कि परीक्षण के लिए सामान्य रूप से तेजी लाने और गिरने के लिए नहीं जहां यह आवश्यक नहीं है, ओवरक्लॉकिंग लंबा होना चाहिए। हमें परीक्षण करने में लगभग तीन घंटे लगते हैं, और यह अब लघु पुनरावृत्तियों जैसा नहीं लगता है।

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

लॉग कहाँ लिखें? रिकॉर्डिंग लॉग के लिए एक लोकप्रिय समाधान उन्हें ठेस पर इकट्ठा करना है, क्योंकि यह सबसे यथार्थवादी प्रतिलिपि प्रस्तुत करने योग्य स्क्रिप्ट देता है। लेकिन कई समस्याएं हैं:

• परीक्षण के लिए आपको बिक्री डेटा का उपयोग करने की आवश्यकता होती है, जो हमेशा संभव नहीं होता है;
• प्रक्रिया एक महंगी syslog ऑपरेशन का उपयोग करती है;
• डिस्क लोड हो रही है।

बड़े परीक्षणों के लिए हमारा दृष्टिकोण हमें यहाँ मदद करता है। हम एक परीक्षण वातावरण पर एक डंप लेते हैं, एक बड़ा परीक्षण चलाते हैं और उस समय की सभी चीज़ों के लॉग को रिकॉर्ड करते हैं जो यथार्थवादी स्क्रिप्ट निष्पादित होती है। अगला, हम डेटाबेस का परीक्षण करने के लिए अपने स्वयं के समुद्री उपकरण का उपयोग करते हैं:

1. एक उदाहरण AWS में बनाया गया है;
2. जिस डंप की हमें ज़रूरत है वह तैनात है;
3. Pg_replay लॉन्च किया गया है और आवश्यक लॉग निभाता है;
4. हम अपनी निगरानी का उपयोग प्रोमेथियस + ग्राफाना के परिणाम का विश्लेषण करने के लिए करते हैं। रिपॉजिटरी में डैशबोर्ड के उदाहरण हैं।

मार्च शुरू करते समय, हम बहुत सारे मापदंडों को पारित कर सकते हैं जिन्हें बदला जा सकता है, उदाहरण के लिए, स्क्रिप्ट की तीव्रता।

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

गिरावट की निगरानी

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

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



यह हमारे लिए कैसे काम करता है? एक मास्टर है, जो विधानसभा के बाद, एक परीक्षण बेंच में तैनात किया जाता है। फिर, लोड परीक्षण के साथ कार्यात्मक परीक्षण स्वचालित रूप से समानांतर में चलाए जाते हैं। तब हमें एल्योर में एक रिपोर्ट मिलती है कि कार्यात्मक परीक्षण कैसे लोड हुए।

इस रिपोर्ट में, उदाहरण के लिए, हम देखते हैं कि एक तुलना परीक्षण एक संदर्भ मान के साथ गिर गया है।



कार्यात्मक परीक्षणों में भी, हम किसी ब्राउज़र में ऑपरेशन के निष्पादन समय को माप सकते हैं। या, एक कार्यात्मक परीक्षण बस लोड के तहत ऑपरेशन के निष्पादन समय में वृद्धि के कारण सफल नहीं होता है, क्योंकि क्लाइंट पर टाइमआउट काम करेगा।

इस भाग के लिए परिणाम

• एक यथार्थवादी परीक्षण आपको डेटाबेस को सस्ते में परीक्षण करने और आसानी से कॉन्फ़िगर करने की अनुमति देता है;
• लोड के तहत कार्यात्मक परीक्षण संभव है।

अगला लेख इस बारे में है कि हम लोड परीक्षण के लिए सैकड़ों सर्वर कैसे प्रबंधित करते हैं।