हमारे टैंक। यांडेक्स में तनाव परीक्षण का इतिहास

आज मैं याद करना चाहता हूं कि कैसे तनाव परीक्षण यांडेक्स में दिखाई दिया, अब विकसित और व्यवस्थित।



वैसे, यदि आप इस कहानी को पसंद करते हैं, तो 30 नवंबर को हमारे सेंट पीटर्सबर्ग कार्यालय में बुधवार को टेस्ट करें ( रजिस्टर करें ) - वहां मैं परीक्षण में गेम मैकेनिक्स के बारे में अधिक बताऊंगा और मैं आपसे खुशी के साथ बात करूंगा। So.

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

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

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

आने वाली सेवाओं और लोड परीक्षण की बढ़ती लोकप्रियता के साथ समानांतर में, या सेवा टीमों के आत्म-जागरूकता के विकास के साथ, उपकरण की क्षमताओं की सीमाओं के बारे में समझ आई।

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



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





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

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



हम अपने तनाव परीक्षण में 2011 को एक महत्वपूर्ण मोड़ मानते हैं। विकास टीम का नेतृत्व आंद्रेई अंडर पोहिल्को ने किया। परीक्षक समुदाय उन्हें जेमीटर के लिए महान प्लगइन्स के डेवलपर के रूप में जानता है। एंड्री ताजा विचारों और दृष्टिकोणों को लाया जो अब काम में बहुत सहायक हैं।

सबसे पहले, हमने महसूस किया कि पुराने प्रतिमान में उपकरण विकसित करना "समझाने का कोई समय नहीं है, कोड" विफल रहता है, और एक मॉड्यूलर विकास प्रतिमान पर स्विच किया जाता है, जहां पूरे प्रोजेक्ट के लिए खतरा पैदा किए बिना एक बड़े मोनोलिथ को घटकों में तोड़ दिया जाता है और अलग से विकसित किया जाता है। दूसरे, चूंकि लोड परीक्षण के आदेश उन सेवाओं से आने लगे थे जो http-ट्रैफिक में रुचि नहीं रखते थे, हमें एक ऐसे उपकरण की आवश्यकता थी जो SMTP / POP3 / FTP / DNS और अन्य प्रोटोकॉल का परीक्षण कर सके। ऐसी प्रत्येक सेवा के लिए प्रेत-लकड़ियों को लिखना महंगा लग रहा था, और हमने लुनपार्क में एक नियमित जेटर बनाने का फैसला किया। इस प्रकार, थोड़े प्रयास से, हमने लोड परीक्षण में दर्जनों नए प्रोटोकॉल का समर्थन करना सीखा। एंबेडिंग ने हमें जेमीटर जीयूआई पर स्विच किए बिना मानक वेब इंटरफ़ेस को छोड़ने में मदद की। Jmeter को सपोर्ट करने के अलावा, हमारे टैंक ने अंततः SSL, IPv6, UDP, अण्डाकार, "मल्टीटैस्ट" को एक ही जनरेटर से कई पतों पर पहुँचाना सीखा, वितरित जनरेटर से कई मिलियन आरपीएस का लोडिंग, और बहुत कुछ सीखा।

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

• प्रोटोटाइप या प्रयोगात्मक असेंबलियों का परीक्षण करने के लिए, हमने लोड जनरेटर का एक अलग संस्करण बनाया और, अधिक तैयार परियोजनाओं से लोड-असर कर्मियों को विचलित नहीं करने के लिए, हमने अपने प्रोटोटाइप के लोड परीक्षणों को डिबग करने के लिए डेवलपर्स या सिस्टम प्रशासकों को इसकी सिफारिश करना शुरू किया। परिणाम लुनपार्क ढांचे के साथ संगत हैं और कोई भी स्थिति नहीं है "मैंने अबू का उपयोग करके अपने प्रोटोटाइप का परीक्षण किया, इसने 1000 आरपीएस दिए, और लुनपार्क में केवल 500!"
• एक बार या ईवेंट सेवाओं का परीक्षण करने के लिए, जहां लोड अचानक कई बार बढ़ सकता है (खेल, एकीकृत राज्य परीक्षा, समाचार, प्रोमो-प्रोजेक्ट), हम त्वरित-लिफ्ट वर्चुअल मशीन रखते हैं जहां तैयार-किए गए बंडल सेवाओं को रोल आउट किया जाता है। लोड ऑब्जेक्ट से रिमोट टेलीमेट्री को हटाने के साथ मैनुअल मोड में टेस्ट किए जाते हैं। कभी-कभी प्रक्रिया को विशेष चैट रूम में समन्वित किया जाता है, जहां 5-10 लोग बैठ सकते हैं: "टैंकर", डेवलपर्स, प्रबंधक। हमारे आंतरिक आँकड़ों के अनुसार, मैनुअल परीक्षण के 50% (!) विभिन्न प्रदर्शन समस्याओं को पकड़ते हैं - गलत तरीके से निर्मित अनुक्रमित, फ़ाइल संचालन पर "स्पाइक्स", श्रमिकों की अपर्याप्त संख्या, आदि से। अंतिम परिणाम JIRA द्वारा प्रलेखित हैं।

एक परीक्षण के लिए एक ऑनलाइन पृष्ठ का एक उदाहरण।


विश्लेषण के लिए, वैकल्पिक ग्राफ़ को शामिल किया जा सकता है, जैसे प्रतिक्रिया समय।



HTTP और नेटवर्क त्रुटियाँ:



बातचीत के विभिन्न चरणों में टाइम्स और प्रवाह:



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

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



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

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