प्रदर्शन अनुसंधान परिचय

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

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

सिद्धांत की बिट

कल्पना करें कि हमारे पास एक निर्वात में एक गोलाकार अनुप्रयोग है - यह अनुरोधों को प्राप्त करता है और उन्हें उत्तर देता है। सादगी के लिए, यह एक ऐसी विधि के साथ एक microservice हो सकता है जो कहीं भी नहीं जाता है और अन्य घटकों या अनुप्रयोगों पर निर्भर नहीं करता है। इस मामले में, हमें इस बात पर ज्यादा दिलचस्पी नहीं है कि यह किस पर लिखा गया है, यह कैसे काम करता है और इसे किस वातावरण में लॉन्च किया गया है।

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

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

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

बढ़ती क्वेरी की तीव्रता, प्रतिक्रिया समय और त्रुटि दर में वृद्धि के साथ

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

सामान्य और अधिकतम प्रदर्शन की स्थिति

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

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

प्रयोगों

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

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

हमारे प्रयोगों में, हम धीरे-धीरे तीव्रता को प्रति मिनट 10 मिनट के लिए 0 से 1000 अनुरोधों तक बढ़ाते हैं। यह सेवा को संतृप्ति तक पहुंचने के लिए पर्याप्त है, और फिर, यदि आवश्यक हो, तो हम अगले प्रयोग में समय और तीव्रता को समायोजित करते हैं ताकि अधिक सटीक परिणाम मिल सके। ऊपर दिए गए ग्राफ़ पर, सब कुछ सुचारू और सुंदर था, लेकिन वास्तविक दुनिया में सामान्य प्रदर्शन के मूल्य को निर्धारित करना पहली नज़र में मुश्किल हो सकता है।

समय पर सेवा प्रदर्शन की वास्तविक निर्भरता

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

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

किसी प्रयोग के परिणाम का त्वरित मूल्यांकन करने के लिए, निम्नलिखित मीट्रिक के रूप में प्राप्त आंकड़ों को एकत्र करना सुविधाजनक है:

• औसत प्रतिक्रिया समय
• मंझला,
• 90% प्रतिशत
• % त्रुटी
• प्रदर्शन।

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

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

प्रतिक्रिया समय का सामान्य वितरण। इस वितरण के साथ, माध्य और माध्य समान हैं

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

लंबे उत्तर के "आउटलेर्स" के साथ प्रतिक्रिया समय का वितरण। इस वितरण के साथ औसत औसत से अधिक है।

ऐसे मामलों में अतिरिक्त विश्लेषण की आवश्यकता होती है। "उत्सर्जन" के पैमाने का अनुमान लगाने के लिए, मात्रात्मक या प्रतिशतक बचाव के लिए आते हैं।

एक नमूना, प्राप्त नमूने के संदर्भ में, प्रतिक्रिया समय का मूल्य है, जिसमें सभी अनुरोधों का संगत हिस्सा फिट बैठता है। यदि आप प्रश्नों का% उपयोग करते हैं, तो यह प्रतिशतक है (वैसे, माध्य 50% प्रतिशत है)। उत्सर्जन का अनुमान लगाने के लिए 90% प्रतिशत का उपयोग करना सुविधाजनक है। उदाहरण के लिए, प्रयोग के परिणामस्वरूप, 100 एमएस का एक माध्य प्राप्त किया गया था, और औसत - 250 एमएस, औसत से 2.5 गुना अधिक है! जाहिर है, यह पूरी तरह से अच्छा नहीं है, हम एक 90% मात्रात्मक को देखते हैं, और वहां 1000 एमएस - जितना कि सभी सफल अनुरोधों का 10% एक सेकंड से अधिक के लिए पूरा किया गया, एक गड़बड़, आपको समझने की आवश्यकता है। लंबे प्रश्नों के लिए खोज करने के लिए, आप प्रयोग परिणामों के साथ या सेवा लॉग पर तुरंत फ़ाइल में काट सकते हैं, लेकिन औसत प्रतिक्रिया समय को ग्राफ बनाम समय के रूप में प्रस्तुत करना और भी बेहतर है, यह तुरंत उपलब्ध "आउटलेयर" के समय और प्रकृति दोनों को दिखाएगा।

परिणाम

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

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

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