वेब परियोजना का परीक्षण लोड करें - कोई नकद नहीं

दोस्तों, शुभ दोपहर!

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

वेब प्रोजेक्ट का परीक्षण क्यों लोड करें?

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

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

हेयूरिस्टिक्स अक्सर अच्छी तरह से काम करते हैं, लेकिन परियोजना जितनी बड़ी और भारी होती है, उतनी ही तेजी से बढ़ती संभावना के साथ कुछ गलत हो सकता है।

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

यही कारण है, वैसे, अंतर्निहित MySQL क्वेरी कैश का उपयोग करने की अनुशंसा नहीं की जाती है, जो इसी तरह की समस्या से ग्रस्त है: यदि आप कम से कम एक तालिका रिकॉर्ड बदलते हैं, तो तालिका कैश पूरी तरह से रीसेट हो जाती है (100k लाइनों की एक तालिका की कल्पना करें और स्थिति की बेरुखी स्पष्ट हो जाती है)।

MySQL प्रश्नों के साथ एक समान स्थिति। यदि प्रश्नों को अनुक्रमणिका द्वारा निष्पादित किया जाता है, तो, सामान्य तौर पर, प्रश्नों को निष्पादित किया जाएगा ... "अधिक तेज़।" आप यह मान सकते हैं कि इस तरह के प्रश्नों का निष्पादन समय डेटा (O (log (n))) की मात्रा पर तार्किक रूप से निर्भर करता है। लेकिन व्यवहार में यह अक्सर पता चलता है कि कुछ प्रश्न दूसरों को प्रभावित करते हैं, एक ही समय में डेटाबेस के सामान्य सबसिस्टम (डिस्क पर छंटनी जो धीमा होना शुरू होता है) का उपयोग करते हुए और आप तुरंत इसका अनुमान नहीं लगा सकते हैं।

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

कभी-कभी वे MySQL में अस्थायी तालिकाओं के लिए पथ को डिस्क में स्थापित करने के लिए भूल जाते हैं जो डेटा को RAM ("/ dev / shm") में मैप करता है, जिसके कारण, जब लोड बढ़ता है, तो डेटाबेस सर्वर गहन छंटाई से नीचे झुक जाता है।

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

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

तनाव परीक्षण लक्ष्यों की पहचान कैसे करें?

यहां यह समझना महत्वपूर्ण है कि तनाव परीक्षण के दौरान वास्तव में आप और ग्राहक दोनों को वेब सिस्टम की गुणवत्ता का स्तर क्या दिखाता है। तनाव परीक्षण लक्ष्य, अच्छे और बुरे के ठोस उदाहरणों से बेहतर कुछ नहीं है:

• 1 मिलियन हिट्स किए। औसत वेबपेज बिल्ड समय = 1 सेकंड। यह क्या दिखाता है? ओह, कुछ भी नहीं। लोड परीक्षण कितने समय तक चला? किसी भी अनुरोध का निष्पादन समय 1 एमएस या 600 सेकंड हो सकता है, और यह स्पष्ट नहीं है कि अनुपात क्या बड़ा है। और कितनी त्रुटियां थीं ("त्रुटि 50x" की शैली में nginx प्रतिक्रिया) भी स्पष्ट नहीं है :-)
• 1 मिलियन हिट्स किए। माध्य वेब पेज का निर्माण समय = 1 सेकंड, HTTP त्रुटियों की संख्या 0.5% है यह क्या दिखाता है? अब तक, थोड़ा उपयोगी, लेकिन बेहतर। अपर्याप्त त्रुटियों का हिस्सा जिसे ग्राहक पकड़ सकता है, हम पहले से ही जानते हैं कि यह बहुत अच्छा है और आप फार्मेसी में जाना और तैयार करना शुरू कर सकते हैं। मंझला औसत से अधिक "मजबूत" अनुमान के लिए एक मीट्रिक प्रतिरोधी है (अधिक "मजबूत" अनुमान), इसलिए, यह निस्संदेह अंकगणितीय औसत से बेहतर है। लेकिन चलो मेट्रिक्स को और भी उपयोगी बनाते हैं।
• प्रति दिन 1 मिलियन हिट बनाए गए थे। 25% हिट 10 एमएस से कम में किए गए, 50% हिट 1 सेकंड से भी कम समय में किए गए (यह औसत या 50 प्रतिशत है), 75% हिट 1.5 सेकंड से कम समय में किए गए, 95% हिट इससे कम में किए गए 5 सेकंड और HTTP त्रुटियों की संख्या 0.5% है! हम अपर्याप्त त्रुटियों के अनुपात को देखते हैं जो ग्राहक पकड़ सकते हैं, लेकिन हम उन अनुरोधों के अनुपात को भी देखते हैं जो एक निश्चित सीमा पर निष्पादित होते हैं।

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

कुछ भी स्पष्ट नहीं है: प्रतिशत, मंझला, मात्रा, ड्राफ्ट, वितरण ...

सब कुछ सरल है! अब मैं डेटा विश्लेषण के लिए एक सुंदर वातावरण में आकर्षित और दिखाऊंगा: जुपिटर नोटबुक / पायथन।

मान लीजिए कि मिलीसेकंड में इतने समय के साथ वेबसाइट पर 10 हिट किए गए:



अब आरोही क्रम में हिट को पूरा करने में लगने वाले समय को क्रमबद्ध करें:



हम मध्यस्थों, 25 और 75 प्रतिशत लोगों को समझने से एक कदम दूर हैं। सब कुछ सरल है - हम चार्ट को आधे में विभाजित करते हैं और बीच में एक "माध्यिका" (चार्ट पर नंबर 1) होगा। ग्राफ की पहली तिमाही 25 वें प्रतिशताइल (ग्राफ पर नंबर 2) के अनुरूप होगी और तीसरी तिमाही 75 वें प्रतिशताइल (ग्राफ पर नंबर 3) के अनुरूप होगी। तदनुसार, अन्य प्रतिशतताएं प्राप्त की जाती हैं (या, जैसा कि उन्हें भी कहा जाता है, क्वांटाइल्स) - 90, 95, 99, आदि।



और यह उपरोक्त हिट्स के निष्पादन समय पर वितरण (हिस्टोग्राम) की तरह दिखेगा। जैसा कि आप देख सकते हैं, सब कुछ बहुत स्पष्ट और सरल है:



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

#!/bin/bash TOTAL=`cat /var/log/nginx.access.log | wc -l` echo "Total:" $TOTAL cat /var/log/nginx.access.log | awk -F'->' '{ $2=$2*1000; zone = int($2/100)*100; hits[zone]++; } \ END {for (z in hits) {printf("%8s ms: %8s,%6.2f% ",z,hits[z],hits[z]/total*100);{s="";a=0;while(a++<int(hits[z]/total*100)) s=s"*";print s} } }' \ total="$TOTAL" - | sort -n 

और आपको कुछ ऐसा मिलता है:



मुझे उम्मीद है कि अब सब कुछ स्पष्ट और जगह पर हो गया है। यदि नहीं, तो टिप्पणियों में पूछें।

तनाव परीक्षण का समय

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

लोड संतुलन

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

• घर - समाचार - विस्तृत समाचार = 50%
• घर - सूची अवलोकन - विस्तृत सूची = 30%
• विस्तृत सूची - सूची अवलोकन - विस्तृत सूची = १५%
• खोज परिणाम - विस्तृत सूची = 5%

लोड बनाने के लिए सॉफ़्टवेयर में (हम अक्सर Jmeter का उपयोग करते हैं), प्रत्येक श्रृंखला के लिए बहुत सारे लोड प्रवाह बनाए जाते हैं ताकि, श्रृंखला में हिट के बीच के अंतराल को ध्यान में रखते हुए, प्रति यूनिट समय के प्रत्येक श्रृंखला के हिट की कुल संख्या 50%, 30%, 15%, 5% के रूप में सहसंबद्ध हो। ।

अंतराल और लोड प्रवाह की गणना एक्सेल में या एक पेंसिल के साथ शीट पर करना आसान है।

लोड श्रृंखला संरचना

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



यह घोड़े के लिए स्पष्ट है कि तनाव परीक्षण के दौरान कैटलॉग के केवल एक विस्तृत पृष्ठ को खींचना असंभव है, इसलिए सीएसवी फ़ाइल से उनकी सूची को पढ़ना और घुमाना उपयोगी है:



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



भार श्रृंखलाओं के वैश्विक चर, उनके थ्रेड्स की संख्या सहित, कॉन्फ़िगर करना आसान है। कुछ वैश्विक चर का उपयोग लोड श्रृंखला में विभिन्न स्थानों पर किया जा सकता है:

तनाव परीक्षण को सुरक्षित रूप से कैसे समाप्त करें?

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

लेकिन यह समझने के लिए कि सब कुछ क्यों गिर गया है और मरम्मत करने के लिए, ग्राहक को एक दिन में "सफल" लोड परीक्षण के परिणाम दिखाने के लिए, आपको पहले ऑपरेटिंग सिस्टम के जीवन के मुख्य मैट्रिक्स की रिकॉर्डिंग को सक्षम करना होगा - यह मुफ्त मुनुन / कैक्टि श्रेणी के उत्पादों में करना आसान है।

मैं सूचीबद्ध करूंगा कि एक वेब सिस्टम के पतन के दौरान सबसे अधिक बार क्या होता है और यह कैसे तय किया जा सकता है।

सबसे पहले, अपाचे या php-fpm वेब सर्वर अनुरोधों के साथ "भरा हुआ" है:



MySQL के पतन के कारण अक्सर ऐसा होता है - फांसी क्वेरी की संख्या बढ़ रही है:



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



यहां आप स्वैप के साथ काम करते समय अचानक होने वाली गतिविधि को देख सकते हैं, आपको यह समझने की आवश्यकता है कि कौन स्वैप में गिर गया और कहां:



हालांकि, कभी-कभी समस्या धीमी डिस्क सबसिस्टम की तरफ होती है। इस मामले में, एलए तेजी से बढ़ता है और डिस्क उपयोग का प्रतिशत 100 (निचले दाएं ग्राफ) तक पहुंचता है:





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

तनाव परीक्षण के परिणामों की व्याख्या

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

• क्लाइंट के अनुरोध के समय के साथ nginx के लिए अनुरोधों का लॉग (इस मामले में यह लोड सॉफ्टवेयर होगा), nginx से Apache / php-fpm को प्रॉक्सी समय
• nginx त्रुटि लॉग
• अपाचे / php-fpm अनुरोध अनुरोध प्रसंस्करण समय और HTTP प्रतिक्रिया स्थिति के साथ लॉग इन करें
• अपाचे / php-fpm त्रुटि लॉग
• MySQL स्लो लॉग
• MySQL त्रुटि लॉग

इसके अतिरिक्त, सीपीयू, डिस्क, माईएसक्यूएल, रैम, अपाचे श्रमिकों आदि के उपयोग पर बीते दिन का विश्लेषणात्मक ग्राफ होना चाहिए। (मुनिन रेखांकन के उपरोक्त उदाहरण देखें)।

इन कलाकृतियों के बाद, आप पोस्ट की शुरुआत में एक साधारण awk-script का उपयोग कर सकते हैं, इन लॉग पर वितरण (हिस्टोग्राम) का निर्माण कर सकते हैं और HTTP त्रुटियों की संख्या और प्रकारों की गणना कर सकते हैं। वास्तव में, आप इस सामग्री के बारे में तनाव परीक्षण की सफलता पर एक रिपोर्ट उत्पन्न कर सकते हैं जो व्यापार और निर्णय लेने के लिए बहुत ही विशिष्ट और उपयोगी है:

दिन के दौरान 1 मिलियन हिट्स किए। 50% से कम हिट में 25% हिट किए गए, 50% हिट 0.5 सेकंड (औसत) से कम में किए गए, 75% हिट 1 सेकंड से कम में किए गए, 95% हिट 5 सेकंड से कम में किए गए, HTTP त्रुटियों की संख्या - 0.01%। परीक्षण डेटा: कैटलॉग, उपयोगकर्ता, समाचार, लेख अपेक्षित के करीब मात्रा में भर गए थे। एक डेवलपर ने खुद को गोली मार ली।

लोड चेन:

घर - समाचार - विस्तृत समाचार = 50%
घर - सूची अवलोकन - विस्तृत सूची = 30%
विस्तृत सूची - सूची अवलोकन - विस्तृत सूची = १५%
खोज परिणाम - विस्तृत सूची = 5%

सर्वर संसाधन उपयोग चार्ट:
...

यह वेब सिस्टम के लोड परीक्षण पर एक अच्छी और समझने योग्य रिपोर्ट है। तीव्र दर्द के प्रेमियों के लिए, आप अभी भी लोड परीक्षण के दौरान सिफारिश कर सकते हैं कि किसी वेबसाइट के वर्ग एसएपी, 1 सी, आदि से डेटा के हर मिनट के आयात-निर्यात को शामिल किया जाए। बाह्य विनिमय सेवाओं के साथ टीसीपी / आईपी सॉकेट पर तुल्यकालिक कनेक्शन, कहते हैं, क्रिप्टोकरेंसी :-)

लेकिन, ईमानदार होने के लिए, यदि आयात-निर्यात सावधानीपूर्वक और ईमानदारी से किया जाता है, तो परीक्षण लोड करना और ऐसी परिस्थितियों में व्यापार के लिए स्वीकार्य आंकड़े दिखाई देंगे।

तनाव परीक्षण कहाँ से आते हैं?

वैसे, हमने इस क्षण को उजागर नहीं किया। तुच्छ कारणों से, नगीनक्स - अपाचे - मायस्कल श्रमिकों के बीच संतुलन की कमी आमतौर पर पॉप अप होती है। यानी श्रमिकों को ऊपर से सीमित नहीं किया जाता है, परिणामस्वरूप, 500 श्रमिक (प्रत्येक कभी-कभी 100 एमबी प्रत्येक) तुरंत अपाचे में जा सकते हैं और 500 धागे अनुरोध के साथ तुरंत MySQL में आएंगे - जो HTTP 50x त्रुटियों में वृद्धि और संभावित पतन का कारण होगा।

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

अधिक कष्टप्रद कारणों में, सीगफॉल्ट पीएचपी हो सकता है। इस मामले में, आपको coredump संग्रह को सक्षम करने और gdb का उपयोग करने की आवश्यकता है कि यह क्यों होता है। ज्यादातर मामलों में, PHP को अपडेट / कॉन्फ़िगर करने के माध्यम से समस्या को कम किया जा सकता है।

पर्दे के पीछे क्या रहता है

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

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

गंभीरता से, अगले पदों में हम इस महत्वपूर्ण विषय को कवर करने की उम्मीद करते हैं।

सारांश और निष्कर्ष

कुल - विकास और व्यवसाय के लिए उपयोगी वेब प्रणाली के लोड परीक्षण के आयोजन और संचालन में कुछ भी जटिल नहीं है।

लोड परीक्षण, ठीक से व्यवस्थित, हमेशा बाहर किया जाना चाहिए - अन्यथा मुकाबला ऑपरेशन के दौरान बड़ी परेशानियों में चलने का जोखिम है, जिसे कुछ दिनों में समाप्त नहीं किया जा सकता है।

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

गुड लक दोस्तों और टिप्पणियों में सवाल पूछें!