रात में फायरिंग, या क्यों लोड लोड - डरावना नहीं

"और अगर आप गोली नहीं मारेंगे, तो मैं खराब हो जाऊंगा"

कुछ समय पहले तक यह माना जाता था कि सेवा को सिर्फ काम करना चाहिए। उन्होंने आकर्षित किया, बनाया, स्क्रिप्ट लिखी - सब कुछ ठीक लग रहा है, आप इसे ठेस के लिए रोल कर सकते हैं।

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

मैं विक्टर बोडोव हूं, मैं यैंडेक्स में काम करता हूं। उत्पादकता अनुसंधान टीम में काम करता हूं और मैं इस बारे में बात करना चाहता हूं कि उत्पादन पर सीधे उत्पादकता का अध्ययन करना कैसे उपयोगी है।

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

इस पर शोध क्यों?

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

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

तीसरा, अप-टू-डेट प्रदर्शन डेटा पर भरोसा करते हुए, व्यवसाय के लिए सेवा के विकास की योजना बनाना और विकास दिशाओं को चुनना आसान होता है।

पहली बार ऐसी समस्या से घिरे लोगों के लिए, यह सवाल उठता है: उत्पादकता कहाँ और कैसे मापें? अक्सर, इस तरह के प्रयोगों के लिए एक बेंच का उपयोग किया जाता है। व्यक्तिगत कंपनियों में, प्रदर्शन अनुसंधान के लिए एक विशेष स्टैंड है। यदि आपके पास है - महान! यदि यह 1 में 1 उत्पाद से मेल खाती है, तो आपके साथ सब कुछ ठीक है। लेकिन अक्सर यह एक स्टैंड को बनाए रखने के लिए बहुत महंगा होता है जो उत्पाद से पूरी तरह से मेल खाता है। कैसे हो सकता है? यह पता चला है कि उत्पाद के साथ पूरी तरह से मेल खाता एकमात्र उत्पाद ही है?

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

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

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

इस तरह के प्रयोगों का डेटा सभी इंजीनियरों के लिए दिलचस्पी का होगा, चाहे उनकी भूमिका कितनी भी हो: डेवलपर्स, परीक्षक, व्यवस्थापक। गारंटीकृत प्रदर्शन संकेतक व्यवसाय को भी रुचि देंगे - संभावित ग्राहकों के लिए वे सेवा के एक ठोस विज्ञापन होंगे।

परिदृश्य चयन और लोड प्रवाह पैटर्न

ऐसे प्रयोगों के सुरक्षित और उचित संगठन के लिए, कई अनिवार्य कदमों को पूरा किया जाना चाहिए।

परिदृश्य चयन

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

प्राथमिकता समूह में किन परिदृश्यों को शामिल किया जाना चाहिए?

• जिनके लिए उपयोगकर्ता गतिविधि में वृद्धि निकट भविष्य में होने की उम्मीद है।
• वे जिनके लिए लगातार तंग प्रतिबंध (विभिन्न कारणों से) हैं जो आपको SLA से नीचे गिरने की अनुमति नहीं देते हैं।

इस प्रकार, उत्पादों पर नियमित जांच के लिए प्राथमिकता परिदृश्यों का एक पूल बनाना संभव है। हमारी कंपनी में, हम कम से कम एक तिमाही में उन पर गोलीबारी करते हैं।

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

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

लोड सर्किट

दूसरे चरण में, हम इनपुट इंटेंसिटी फीड सर्किट का चयन करते हैं।

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

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

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

एक्स अक्ष - समय, वाई अक्ष - लोड तीव्रता (प्रति सेकंड अनुरोध)

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

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

समय की पसंद

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

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

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

समकक्षों के साथ काम करने में कठिनाइयाँ

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

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

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

सुरक्षा परिषद, वित्तीय विभागों, प्रवेश के साथ पहुंच और समन्वय की जाँच करना

इस भाग में, हम सभी जिम्मेदार व्यक्तियों - सुरक्षा सेवा, वित्तीय विभागों और सिस्टम प्रशासकों के साथ पहुंच और अनुमोदन पर ध्यान केंद्रित करेंगे।

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

पहुंच प्राप्त करने के बाद, आपको सबसे छोटी इकाई स्ट्रीम पर स्क्रिप्ट को डीबग करना और जांचना होगा।

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

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

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

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

परिणामों की फायरिंग और विश्लेषण

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

रोकने के कई कारण हैं।

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

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

परिणाम विश्लेषण

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

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

सफल अनुसंधान, और उपयोगकर्ता सुरक्षा याद रखें!