हमने प्रदर्शन परीक्षण के लिए रूपरेखा को कैसे चुना और घुमाया

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



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

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

नीचे एक ग्राफ दिखाया गया है कि सिस्टम में डेटा की वृद्धि के साथ प्रति सेकंड बैकएंड द्वारा संसाधित एपीआई की संख्या कैसे बदल जाती है



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

ऐसी स्थितियों को बाहर करने के लिए, हम कई बार डेटा की मात्रा बढ़ाते हैं, समानांतर थ्रेड्स की संख्या में वृद्धि करते हैं यह समझने के लिए कि लोड नाटकीय रूप से बढ़ता है तो सेवा कैसे व्यवहार करेगी।

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

Acronis में प्रदर्शन परीक्षण की विशेषताएं

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

POST /animals PUT /animals/<id> GET /animals?filter=criteria 

1 और 2 एपीआई को साइजिंग टेस्ट में कहा जाता है - वे सिस्टम में नई संस्थाओं की संख्या में वृद्धि करते हैं।
3 एपीआई हैं जिन्हें उपयोग चरण में कहा जाता है। इस एपीआई में फ़िल्टरिंग विकल्पों का एक टन है। तदनुसार, एक से अधिक परीक्षण होंगे

इस प्रकार, पुनरावृत्त आकार और उपयोग परीक्षण चलाकर, हमें इसके विकास के साथ सिस्टम के प्रदर्शन में बदलाव की तस्वीर मिलती है

ढांचे की जरूरत ...

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

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

तो, एक रूपरेखा का चुनाव कार्य द्वारा निर्धारित किया गया था। और हमारा काम है:

• एपीआई अड़चन ढूँढना
• उच्च भार के प्रतिरोध की जाँच करें
• डेटा वॉल्यूम की वृद्धि के साथ सेवा की प्रभावशीलता का मूल्यांकन करें
• समय के साथ होने वाली संचयी त्रुटियों को पहचानें

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

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

 PUT /endpoint/resource/<id> 

इस मामले में, आपको पहले से जानना आवश्यक है कि हम उस संसाधन की <id> जिसे हम शुद्ध क्वेरी निष्पादन समय को मापने के लिए बदलना चाहते हैं।

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

तेजी से

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

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

नतीजतन, हमने K6 ढांचे को चुना, जो हमें पूर्ण जावास्क्रिप्ट में स्क्रिप्ट का वर्णन करने की अनुमति देता है, और ऊपर-औसत प्रदर्शन प्रदान करता है। यह ढांचा गो में लिखा गया है, और तेजी से लोकप्रियता हासिल कर रहा है। उदाहरण के लिए, गितुब पर, इस परियोजना को पहले से ही लगभग 5.5 हजार सितारे मिले हैं! K6 सक्रिय रूप से विकसित हो रहा है, और समुदाय ने पहले से ही लगभग 3 हजार कमिट का प्रस्ताव दिया है, और परियोजना में 50 योगदानकर्ता हैं जिन्होंने 36 कोड शाखाएं बनाई हैं। बेशक, K6 अभी भी आदर्श से बहुत दूर है, लेकिन धीरे-धीरे रूपरेखा बेहतर हो रही है, और आप यहां Jmeter के साथ इसकी तुलना के बारे में पढ़ सकते हैं।

कठिनाइयों और उनके समाधान

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

आप विभिन्न तरीकों से अपनी जरूरत का डेटा प्राप्त कर सकते हैं:

• आप उन्हें एपीआई के माध्यम से अनुरोध कर सकते हैं
• आप डेटाबेस तक सीधी पहुंच का उपयोग कर सकते हैं

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

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

तैयार रूपरेखा

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

अगली पोस्ट में, मैं बात करूँगा कि कैसे हमने न्यूनतम संसाधनों के साथ सैकड़ों-हज़ारों कनेक्शनों के एक साथ कनेक्शन का समर्थन करने वाली सेवा के परीक्षण की समस्या को हल किया।