ई-कॉमर्स बड़े पैमाने पर पदोन्नति कैसे बचता है। वेब पर चोटी के भार के लिए तैयार होना [भाग 1]

सभी को नमस्कार, मैं एलेक्सी प्रिस्टावको, डेटालाइन वेब परियोजना निदेशक के संपर्क में हूं।
ब्लैक फ्राइडे, दुनिया का सबसे बड़ा ई-कॉमर्स कार्यक्रम, नवंबर के आखिरी दिनों में सालाना होता है। यह रिकॉर्ड छूट का समय है, स्टोर लगभग आधी रात को खुलते हैं, और ट्रैफ़िक प्रवाह में तेज वृद्धि को न समझते हुए, एक्शन फॉल में भाग लेने वाली साइटें।

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

ब्लैक फ्राइडे से क्या खतरा

जैसा कि मैंने ऊपर लिखा है, ब्लैक फ्राइडे एक ऐसा दिन है जो ई-कॉमर्स साइटों के रखरखाव में शामिल सभी लोगों के लिए बहुत परेशानी का कारण बनता है।

इसे महसूस करने के लिए, नीचे दिए गए चार्ट पर विचार करें। यह ब्लैक फ्राइडे के दौरान साइट पर अनुरोधों की बढ़ती संख्या को दर्शाता है।



सामान्य दैनिक चोटियों की तुलना में, जब कोई शेयर नहीं होता है, तो ब्लैक फ्राइडे पर यातायात 100-200% बढ़ रहा है, और यह सीमा नहीं है।

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

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

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

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

सामान्य तौर पर, बढ़े हुए यातायात के लिए एक साइट तैयार करने के दो चरण होते हैं: तकनीकी और संगठनात्मक। इस लेख में हम तकनीकी चरण पर चर्चा करेंगे, और मैं दूसरे भाग में संगठनात्मक विवरणों का विस्तार से वर्णन करूंगा, जो एक सप्ताह में जारी किया जाएगा।

साइट की तकनीकी तैयारी

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

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

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

चूंकि साइट के प्रदर्शन के संदर्भ में दो पहलू हैं - प्रतिक्रिया की गति और एक साथ संसाधित अनुरोधों की संख्या, हम इन मापदंडों में सुधार करेंगे।

ज्यादातर, एक व्यवसाय Google Analytics के अनुसार साइट की गति के रूप में प्रतिक्रिया की गति का प्रतिनिधित्व करता है, और साथ ही साथ साइट पर उपयोगकर्ताओं की संख्या के रूप में एक साथ अनुरोधों की संख्या।

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

हम प्रतिक्रिया की गति का अनुकूलन करते हैं

प्रतिक्रिया की गति का अनुकूलन करते समय, हम दो संकेतकों में रुचि रखते हैं: सर्वर प्रतिक्रिया की गति और पृष्ठ लोड समय।

पृष्ठ लोड समय में निम्नलिखित लिंक हैं:

• सर्वर पेज पीढ़ी का समय;
• पेज ट्रांसफर का समय सर्वर से क्लाइंट तक;
• ग्राहक के ब्राउज़र में पृष्ठ प्रसंस्करण समय।

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

1. इंटरनेट चैनल के लोड की जाँच करें। अनुमानित वृद्धि को गिनें। यदि संदेह है, तो चैनल का विस्तार करें। कुछ प्रदाता, निरंतर आधार पर महंगे एक्सटेंशन के अलावा, आपको पीक अवधि (बहुत सस्ता) के लिए एक अस्थायी एक्सटेंशन की पेशकश कर सकते हैं या यहां तक ​​कि आपको कुछ समय के लिए अधिकतम गति से अधिक होने की अनुमति दे सकते हैं।
2. CDN का उपयोग करना? तकनीकी सहायता से संपर्क करें और नियोजित यातायात वृद्धि के बारे में चेतावनी दें। वे सामान्य चोटी के लिए भी तैयारी कर रहे हैं, और आपका पूर्वानुमान काम आएगा। यदि CDN वादा करता है कि सब कुछ ठीक हो जाएगा, लेकिन, सब कुछ के बावजूद, "लेट" होगा, पत्राचार की उपस्थिति मुआवजे के लिए आगे के दावों को लगाने में मदद करेगी।
3. अग्रिम में, समस्याओं के मामले में बाहरी घटकों को अस्थायी रूप से अक्षम करने के लिए एक स्क्रिप्ट पर काम करें। व्यवसाय के साथ परिदृश्य को संरेखित करें। उपयोग की जाने वाली सेवाओं के तकनीकी समर्थन के साथ संवाद करने के लिए यह ज़रूरत से ज़्यादा नहीं होगा, वैसे भी आमतौर पर उन्हें अन्यथा प्रभावित करना असंभव है।
4. कई साइटों पर, स्थैतिक अनुप्रयोग सर्वर का उपयोग करके प्रदान किया जाता है। उच्च भार के तहत, स्टेटिक्स के लिए अनुरोधों की संख्या कई गुना बढ़ जाती है, और वे आवेदन के साथ संसाधनों के लिए प्रतिस्पर्धा करना शुरू करते हैं। Nginx से सीधे स्टेटिक्स रिटर्न को कॉन्फ़िगर करना सुनिश्चित करें। सबसे पहले, यह इसके साथ बहुत बेहतर सामना करेगा, और दूसरी बात, आपके अपाचे, टॉमकैट या जेट्टी थ्रेड्स के लिए बहुत अधिक उपयोगी काम होगा।

प्रतिक्रिया की गति में सुधार

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

लेकिन व्यवहार में, प्रतिक्रिया की गति को अनुकूलित करने के लिए बहुत सारे स्वतंत्र कार्यों की आवश्यकता होती है। एक बार में सब कुछ अनुकूलित करना असंभव है, लेकिन प्रक्रिया में कुछ तोड़ना आसान है।

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

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

पृष्ठ पीढ़ी की गति हमारे लिए केवल एक और संकेतक के साथ ब्याज की होगी - आने वाले भार की राशि।

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

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

यहाँ एक सामान्य तकनीकी प्रशिक्षण योजना है:

1. वर्तमान संकेतक का पता लगाएं (साइट के वर्तमान संस्करण का लोड परीक्षण करें);
2. यह समझने के लिए कि वास्तव में क्या गायब है और ऑर्डर करने के लिए कितने संसाधनों की आवश्यकता है;
3. संसाधन जोड़ें;
4. तनाव परीक्षण दोहराएं और देखें कि क्या मदद करता है।

बहुत आसान लगता है? आप सही हैं, हर बिंदु कई आश्चर्य से भरा है।

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

आगे, मैं आपको दिखाऊंगा कि संभावित समस्याओं की पहचान कैसे करें और कमजोरियों को ठीक करें। आइए शुरुआत करें कि तनाव परीक्षण कैसे करें और यथार्थवादी परिणाम प्राप्त करें।

हम सही तरीके से लोड परीक्षण करते हैं

परीक्षण कहाँ करना है?

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

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

इसे निम्नलिखित आवश्यकताओं को पूरा करना चाहिए:

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

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

भार कैसे उत्पन्न करें?

1. लॉग से अनुरोध पर परीक्षण

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

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

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

2. Yandex.Tank और फैंटम का उपयोग करना

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

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

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

यह आपको सूट करेगा अगर:

• अधिकृत और अनधिकृत उपयोगकर्ताओं के लिए सर्वर प्रतिक्रिया समय में कोई अंतर नहीं है, या यह नगण्य है;
• HTTP सत्रों के बिना स्पष्ट रूप से एपीआई परीक्षण;
• यह दृष्टिकोण आम तौर पर आपकी साइट के तर्क के अनुरूप है (आमतौर पर ऑनलाइन स्टोर के लिए उपयुक्त नहीं है)।

3. Apache JMeter का उपयोग करना

यह सबसे लचीला उपकरण है जो आपको उपयोगकर्ता सत्रों का विस्तार से अनुकरण करने की अनुमति देता है। तो, इसकी मदद से, आप अभी भी व्यापार के सवाल का जवाब दे सकते हैं "साइट कितने उपयोगकर्ताओं का सामना करती है?" इसके अलावा, JMeter Yandex.Tank के साथ मिलकर काम कर सकता है।
इसका प्रमुख ऋण संसाधन खपत और परीक्षण तैयार करने की जटिलता है।

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

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

तनाव परीक्षण सिफारिशें

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

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

यदि पृष्ठ कई अनुरोधों पर बनाया गया है, तो उनके बीच देरी पर विचार करें। देखें कि उपयोगकर्ता आमतौर पर प्रति सत्र कितने पृष्ठों का दौरा करता है, इस संख्या का वितरण क्या है। पृष्ठ प्रकार द्वारा सबसे आम उपयोगकर्ता पथ के 5-10 को हाइलाइट करें।

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

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

यदि बहुत अधिक पृष्ठ हैं, तो उन्हें ट्रैफ़िक के प्रतिशत के अनुसार कई समूहों में विभाजित करें।

प्रोफाइल केवल JMeter के लिए एक भूमिका निभाते हैं, लेकिन क्वेरी सूचियों का निर्माण करके, आप "टैंक" कारतूस से लैस कर सकते हैं।

और फिर से: उपयोगकर्ता एमुलेशन मोड में जेमीटर का उपयोग करते समय, अनुरोधों के बीच देरी के बारे में मत भूलना। यदि आप उन्हें नहीं जोड़ते हैं, तो आपका उत्पन्न लोड योजनाबद्ध की तुलना में कई गुना अधिक होगा!

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

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

क्या सब कुछ तैयार है? महान, आगे बढ़ो!

हम परीक्षणों में निगरानी का उपयोग करते हैं

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

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

सिद्धांत रूप में, मेजबान इस दृष्टिकोण को पसंद करेगा। आपको सोने के ग्राहक का दर्जा भी मिल सकता है।

लेकिन चालाकी से काम करने से पहले, आइए जानने की कोशिश करें कि वास्तव में क्या गलत हुआ।

संभावित कारणों के समुद्र में आपका जीवन बोया एक निगरानी प्रणाली है।



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

नीचे आपको आरंभ करने में मदद करने के लिए एक सूची दी गई है:

• सीपीयू लोड (सीपीयू उपयोग, सीपीयू लोड);
• रैम लोडिंग;
• डिस्क लोडिंग (IOPS, लेटेंसी);
• नेटवर्क कनेक्शन की संख्या (समय प्रतीक्षा, फिन प्रतीक्षा, बंद प्रतीक्षा, स्थापित);
• खुले सॉकेट की संख्या;
• उपयोगकर्ता प्रक्रियाओं की संख्या;
• खुली फ़ाइलों की संख्या;
• नेटवर्क ट्रैफ़िक (मेगाबिट्स में और पैकेट में, प्लस एरर और ड्रॉप्स)।

और यह भी:

• डेटाबेस और अन्य घटकों के प्रश्नों, प्रतिक्रियाओं और कनेक्शनों की संख्या;
• घटक प्रतिक्रिया गति (डेटाबेस, खोज सर्वर, कैश, आदि);
• त्रुटियों के लिए सभी उपलब्ध लॉग।

. , « ». , «» , .

, , .

- , : , HDD SSD. -, .

. .

: , , ? , , , 2- , - (, 0,5 ) 1,5 . - «, ».

1 , . , . , . , ( ) , .

, , , .

«» , . 2-3 , , .

, : . , . , , , , .

. . , SLA, , , , , «» .

. , . .

, , . , , .

, .
-, ( ), -, . .

, . - , .

, , , « e-commerce. », 16 . .