निरंतर एकीकरण के भाग के रूप में वेब सेवा प्रदर्शन परीक्षण। यांडेक्स अनुभव

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

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

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

क्या महत्वपूर्ण सर्वर मीट्रिक हाइलाइट किए जा सकते हैं?

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

तो चलिए इसे क्रम में लेते हैं।

प्रति सेकंड अनुरोध

हमारे डेवलपर, जो लंबे समय से लोड परीक्षण से निपट रहे हैं, सिस्टम के महत्वपूर्ण संसाधन के बारे में बात करना पसंद करते हैं। आइए देखें कि यह क्या है।

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

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

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

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

क्षमता को दो तरीकों से मापा जा सकता है।

खुला लोड मॉडल (तनाव परीक्षण)

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

उपयोगकर्ताओं की संख्या की गणना करने के लिए, आप लिटिल सूत्र का उपयोग कर सकते हैं (आप इसके बारे में यहां पढ़ सकते हैं)। सिद्धांत को स्वीकार करते हुए, सूत्र इस प्रकार है:

आरपीएस = 1000 / टी * कार्यकर्ता, जहां

• टी - अनुरोध प्रसंस्करण का औसत समय (मिलीसेकंड में);
• श्रमिक - धागे की संख्या;
• प्रति सेकंड 1000 / टी अनुरोध - यह मान एकल-थ्रेडेड जनरेटर द्वारा उत्पन्न किया जाएगा।

बंद लोड मॉडल (लोड परीक्षण)

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

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

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

अनुरोध के अनुसार समय

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

औसत प्रतिक्रिया समय प्राप्त करने के लिए, हम एक ही Yandex.Tank का उपयोग करेंगे। केवल अब हम उत्पादन में आपके सिस्टम के औसत संकेतक के अनुरूप आरपीएस सेट करेंगे। गोलाबारी के बाद हमें प्रत्येक अनुरोध के लिए प्रतिक्रिया समय मिलता है। एकत्रित आंकड़ों के आधार पर, प्रतिक्रिया समय के प्रतिशत की गणना की जा सकती है।

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

निवासी सेट का आकार

हमारा सर्वर सीधे mmap के माध्यम से फाइलों के साथ काम करता है। आरएसएस इंडेक्स को मापते हुए, हम जानना चाहते हैं कि ऑपरेशन के दौरान ऑपरेटिंग सिस्टम से प्रोग्राम ने कितनी मेमोरी ली है।

लिनक्स पर, फ़ाइल / proc / PID / smaps लिखा जाता है - यह एक मानचित्र-आधारित एक्सटेंशन है जो प्रत्येक प्रक्रिया मैपिंग के लिए मेमोरी खपत दिखाता है। यदि आपकी प्रक्रिया tmpfs का उपयोग करती है, तो अनाम और गैर-अनाम मेमोरी दोनों स्मैप्स में मिल जाएँगी। गैर-अनाम मेमोरी में शामिल हैं, उदाहरण के लिए, मेमोरी में लोड की गई फाइलें। यहां स्मैप्स में एक उदाहरण प्रविष्टि है। एक विशिष्ट फ़ाइल निर्दिष्ट की गई है, और इसका पैरामीटर बेनामी = 0kB है।

7fea65a60000-7fea65a61000 r--s 00000000 09:03 79169191 /place/home/.../some.yabs Size: 4 kB Rss: 4 kB Pss: 4 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 4 kB Private_Dirty: 0 kB Referenced: 4 kB Anonymous: 0 kB AnonHugePages: 0 kB Swap: 0 kB KernelPageSize: 4 kB MMUPageSize: 4 kB Locked: 0 kB VmFlags: rd mr me ms 

और यह अनाम मेमोरी आवंटन का एक उदाहरण है। जब एक प्रक्रिया (समान एमएमएपी) ऑपरेटिंग सिस्टम को मेमोरी के एक निश्चित आकार को आवंटित करने के लिए अनुरोध करती है, तो इसके लिए एक पता आवंटित किया जाता है। जबकि इस प्रक्रिया में केवल वर्चुअल मेमोरी होती है। इस बिंदु पर, हमें अभी तक नहीं पता है कि स्मृति का कौन सा भौतिक टुकड़ा आवंटित किया जाएगा। हम एक रिकॉर्ड रहित देखते हैं। यह अनाम मेमोरी आवंटित करने का एक उदाहरण है। सिस्टम को 24572 kB के आकार का अनुरोध किया गया था, लेकिन उन्होंने इसका उपयोग नहीं किया और वास्तव में केवल RSS = 4 kB लिया गया।

 7fea67264000-7fea68a63000 rw-p 00000000 00:00 0 Size: 24572 kB Rss: 4 kB Pss: 4 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 0 kB Private_Dirty: 4 kB Referenced: 4 kB Anonymous: 4 kB AnonHugePages: 0 kB Swap: 0 kB KernelPageSize: 4 kB MMUPageSize: 4 kB Locked: 0 kB VmFlags: rd wr mr mw me ac 

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

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

HTTP त्रुटियां

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

माप सटीकता के बारे में थोड़ा

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

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

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

शोर के साथ और क्या किया जा सकता है?

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

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

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

ऐतिहासिक डेटा के विश्लेषण से पता चलता है कि हार्डवेयर अलग है। यहां "हार्डवेयर" शब्द में कर्नेल संस्करण और अपटाइम के परिणाम (स्पष्ट रूप से, स्मृति में चल कर्नेल ऑब्जेक्ट नहीं) शामिल हैं।

इस प्रकार, प्रत्येक "होस्ट" (रिबूट करने पर, मेजबान "मर जाता है" और एक "नया" प्रकट होता है) हम उस संशोधन को जोड़ते हैं जिसके द्वारा हम एकत्रीकरण से पहले आरपीएस को गुणा करते हैं।

हम संशोधन को बेहद भद्दे तरीके से मानते हैं और अपडेट करते हैं, कुछ सुदृढीकरण प्रशिक्षण विकल्प के बारे में याद दिलाते हैं।

पोस्टहोस्ट सुधार के दिए गए वेक्टर के लिए, हम उद्देश्य फ़ंक्शन पर विचार करते हैं:

• प्रत्येक परीक्षण में हम प्राप्त "आरपीएस" परिणामों के मानक विचलन पर विचार करते हैं
• समान वजन वाले उनसे औसत लें $$$exp ((testtimestamp - now) / tau)$ ।
• हमारे पास ताऊ = 1 सप्ताह है।

फिर हम 1.0 पर एक सुधार (इन भार के सबसे बड़े योग के साथ मेजबान के लिए) को ठीक करते हैं और अन्य सभी सुधारों के मूल्यों की तलाश करते हैं जो न्यूनतम उद्देश्य फ़ंक्शन देते हैं।

ऐतिहासिक डेटा पर परिणामों को मान्य करने के लिए, हम पुराने डेटा पर सुधारों पर विचार करते हैं, हम नए सिरे से सही परिणाम पर विचार करते हैं, बिना सोचे-समझे तुलना करते हैं।

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

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

यदि आप लेख पढ़ते हैं, तो निश्चित रूप से यह आपके लिए दिलचस्प होगा कि आप Yandex.Tank के बारे में एक रिपोर्ट देखें और लोड परीक्षण के परिणामों का विश्लेषण करें।

हम आपको यह भी याद दिलाते हैं कि निरंतर एकीकरण के संगठन के बारे में अधिक विस्तार से हम 25 अक्टूबर को यैंडेक्स की घटना के बारे में अंदर से बात करेंगे। आने के लिए!