हम दूर से x10 लोड में तेज वृद्धि से कैसे बचे और हमने क्या निष्कर्ष निकाला

नमस्ते, हबर! हम पिछले कुछ महीनों से एक बहुत ही दिलचस्प स्थिति में रह रहे हैं और मैं हमारी बुनियादी ढांचे के विस्तार की कहानी साझा करना चाहूंगा। इस दौरान, SberMarket के ऑर्डर 4 गुना बढ़ गए और 17 नए शहरों में सेवा शुरू की गई। किराना डिलीवरी की मांग में विस्फोटक वृद्धि के कारण हमें अपने बुनियादी ढांचे को बढ़ाने की आवश्यकता पड़ी। कट के अंतर्गत सबसे दिलचस्प और उपयोगी निष्कर्षों के बारे में पढ़ें।

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

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

एक दिन, एक ग्राहक ने एक SberMarket कूरियर से संपर्क रहित तरीके से किराने का सामान पहुंचाने के लिए कहा - बालकनी के ठीक सामने

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

स्लेव पूरी तरह से युद्ध की तैयारी में है

महामारी की शुरुआत से पहले ही, हमें अपने बैकएंड सर्वर पर अनुरोधों की संख्या में वृद्धि का सामना करना पड़ा था। होम डिलीवरी के लिए किराने का सामान ऑर्डर करने का चलन जोर पकड़ने लगा और COVID-19 के कारण पहले आत्म-अलगाव उपायों की शुरुआत के साथ, पूरे दिन काम का बोझ नाटकीय रूप से बढ़ गया। मुख्य डेटाबेस के मास्टर सर्वर को शीघ्रता से अनलोड करने और कुछ रीड रिक्वेस्ट को प्रतिकृति सर्वर (स्लेव) में स्थानांतरित करने की आवश्यकता थी।

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

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

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

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

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

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

लेकिन चूंकि हमने न केवल डेटाबेस को डंप किया (उस समय पुनर्स्थापना में लगभग 5 घंटे लगे), बल्कि मास्टर सर्वर का एक स्नैपशॉट भी था, हम 2 घंटे के भीतर प्रतिकृति लॉन्च करने में कामयाब रहे। सच है, इसके बाद हमें प्रतिकृति लॉग के लंबे समय तक चलने का सामना करना पड़ा (क्योंकि प्रक्रिया सिंगल-थ्रेडेड मोड में चलती है, लेकिन यह पूरी तरह से अलग कहानी है)।

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

एक भारी क्वेरी को भी अनुकूलित करने से डेटाबेस को वापस जीवंत बनाया जा सकता है

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

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

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

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

भागीदार सेवाओं के प्रदर्शन की निगरानी व्यवस्थित करें

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

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

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

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

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

कभी-कभी यह पता चलता है कि "और सोना चाहिए"(सी) मदद नहीं करता है

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

अपेक्षित प्रदर्शन में वृद्धि के बजाय, सर्वर बस "मर गया"। यह तुरंत 100% पर लोड हो गया और और भी धीमी गति से प्रतिक्रिया करने लगा। शुरुआत में हमारे पास 2 कोर और 2 जीबी रैम थी। हमने वही करने का निर्णय लिया जो आमतौर पर मदद करता है - हमने सर्वर को 8 कोर और 32 जीबी दिया। सब कुछ बहुत खराब हो गया (हम आपको एक अलग पोस्ट में बताएंगे कि कैसे और क्यों)। 

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

निष्कर्ष: "अधिक लोहा जोड़ें" जैसी मानक विधियाँ हमेशा काम नहीं करती हैं। इसलिए किसी भी सेवा का विस्तार करते समय, आपको इसकी अच्छी समझ होनी चाहिए कि यह संसाधनों का उपयोग कैसे करती है और नई परिस्थितियों में इसके संचालन का पहले से परीक्षण करना चाहिए। 

स्टेटलेस आसान क्षैतिज स्केलिंग की कुंजी है

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

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

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

गहन विकास के लिए 7 सिद्धांत

अतिरिक्त क्षमता की उपलब्धता के बावजूद, हमने विकास की प्रक्रिया में कई गलतियाँ की हैं। इस दौरान ऑर्डर की संख्या 4 गुना से भी ज्यादा बढ़ गई. अब हम पहले से ही 17 शहरों में प्रति दिन 000 से अधिक ऑर्डर वितरित करते हैं और भूगोल को और भी विस्तारित करने की योजना बना रहे हैं - 62 की पहली छमाही में यह सेवा पूरे रूस में लॉन्च होने की उम्मीद है। बढ़ते कार्यभार से निपटने के लिए, हमारे पहले से ही पूर्ण शंकुओं को ध्यान में रखते हुए, हमने निरंतर विकास की स्थितियों में काम करने के लिए 2020 बुनियादी सिद्धांत विकसित किए हैं:

1. घटना का प्रबंधन. हमने जीरा में एक बोर्ड बनाया, जहां प्रत्येक घटना टिकट के रूप में दिखाई देती है। इससे वास्तव में घटना-संबंधी कार्यों को प्राथमिकता देने और निष्पादित करने में मदद मिलेगी। आख़िरकार, संक्षेप में, गलतियाँ करना डरावना नहीं है, लेकिन एक ही अवसर पर दो बार गलतियाँ करना डरावना है। उन मामलों के लिए जहां कारण ठीक होने से पहले घटनाएं दोबारा हो जाती हैं, कार्रवाई के निर्देश तैयार होने चाहिए, क्योंकि भारी भार के समय बिजली की गति से प्रतिक्रिया करना महत्वपूर्ण है।
2. निगरानी बिना किसी अपवाद के सभी बुनियादी ढांचे के तत्वों के लिए आवश्यक। यह उनके लिए धन्यवाद था कि हम भार की वृद्धि की भविष्यवाणी करने और उन्मूलन को प्राथमिकता देने के लिए "अड़चनों" का सही ढंग से चयन करने में सक्षम थे। सबसे अधिक संभावना है, उच्च भार के तहत, वह सब कुछ जिसके बारे में आपने कभी नहीं सोचा था वह टूट जाएगा या धीमा होने लगेगा। इसलिए, पहली घटनाओं के घटित होने के तुरंत बाद उन पर नजर रखने और उनका पूर्वानुमान लगाने के लिए नए अलर्ट बनाना सबसे अच्छा है।
3. सही अलर्ट जब भार तेजी से बढ़ता है तो बस आवश्यक होता है। सबसे पहले, उन्हें रिपोर्ट करना होगा कि वास्तव में क्या टूटा है। दूसरे, बहुत अधिक अलर्ट नहीं होने चाहिए, क्योंकि गैर-महत्वपूर्ण अलर्ट की प्रचुरता सभी अलर्ट को पूरी तरह से अनदेखा कर देती है।
4. आवेदन स्टेटलेस होने चाहिए. हम आश्वस्त हैं कि इस नियम का कोई अपवाद नहीं होना चाहिए। हमें रनटाइम वातावरण से पूर्ण स्वतंत्रता की आवश्यकता है। ऐसा करने के लिए, आप साझा किए गए डेटा को डेटाबेस में या, उदाहरण के लिए, सीधे S3 में संग्रहीत कर सकते हैं। इससे भी बेहतर, नियमों का पालन करें। https://12factor.net. समय में तेज वृद्धि के दौरान, कोड को अनुकूलित करने का कोई तरीका नहीं है, और आपको कंप्यूटिंग संसाधनों और क्षैतिज स्केलिंग को सीधे बढ़ाकर लोड का सामना करना होगा।
5. बाहरी सेवाओं का कोटा और प्रदर्शन. तीव्र विकास के साथ, न केवल आपके बुनियादी ढांचे में, बल्कि बाहरी सेवा में भी समस्या उत्पन्न हो सकती है। सबसे कष्टप्रद बात तब होती है जब ऐसा किसी विफलता के कारण नहीं, बल्कि कोटा या सीमा तक पहुंचने के कारण होता है। इसलिए बाहरी सेवाओं का दायरा भी उतना ही अच्छा होना चाहिए जितना आप करते हैं। 
6. प्रक्रियाओं और कतारों को अलग करें. किसी गेटवे पर रुकावट होने पर यह बहुत मदद करता है। यदि पूर्ण एसएमएस भेजने वाली कतारों ने सूचना प्रणालियों के बीच सूचनाओं के आदान-प्रदान में हस्तक्षेप नहीं किया होता तो हमें डेटा स्थानांतरण में देरी का सामना नहीं करना पड़ता। और यदि श्रमिक अलग-अलग काम करें तो उनकी संख्या बढ़ाना आसान होगा।
7. वित्तीय वास्तविकताएँ. जब डेटा प्रवाह में विस्फोटक वृद्धि होती है, तो टैरिफ और सब्सक्रिप्शन के बारे में सोचने का समय नहीं मिलता है। लेकिन आपको उन्हें याद रखने की ज़रूरत है, खासकर यदि आप एक छोटी कंपनी हैं। किसी भी एपीआई के मालिक के साथ-साथ आपके होस्टिंग प्रदाता को भी बड़ा बिल देना पड़ सकता है। इसलिए आपको अनुबंधों को ध्यानपूर्वक पढ़ने की आवश्यकता है।

निष्कर्ष

नुकसान के बिना नहीं, लेकिन हम इस चरण से बच गए, और आज हम पाए गए सभी सिद्धांतों का पालन करने का प्रयास करते हैं, और प्रत्येक मशीन में कुछ अप्रत्याशित घटनाओं से निपटने के लिए x4 प्रदर्शन को आसानी से बढ़ाने की क्षमता होती है। 

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

केवल पंजीकृत उपयोगकर्ता ही सर्वेक्षण में भाग ले सकते हैं। साइन इन करेंकृपया।

क्या आपने कभी लोड में तेज वृद्धि के कारण सेवा में मंदी/गिरावट का अनुभव किया है:

• 55,6% तक कंप्यूटिंग संसाधनों को शीघ्रता से जोड़ने में असमर्थता10

• 16,7% तक होस्टिंग प्रदाता अवसंरचना सीमाएँ3

• 33,3% तक तृतीय-पक्ष APIs6 की सीमाएँ

• 27,8% तक उनके अनुप्रयोगों के राज्यविहीन सिद्धांतों का उल्लंघन5

• 88,9% तक स्वयं की सेवाओं का गैर-इष्टतम कोड16

18 उपयोगकर्ताओं ने मतदान किया। 6 उपयोगकर्ता अनुपस्थित रहे।

स्रोत: www.habr.com