हम एक सर्वर लिख रहे हैं जो लोड के तहत क्रैश नहीं करता है

एक अनुवादक से: यह मोज़िला आइडेंटिटी टीम से Node.js श्रृंखला का पाँचवाँ लेख है, जो पर्सोना प्रोजेक्ट में शामिल है।

---

Node.js एप्लिकेशन को कैसे लिखना है जो असंभव लोड के तहत भी काम करना जारी रखेगा? यह आलेख नोड-टोबैसी कार्यप्रणाली और पुस्तकालय को दिखाता है, जो इसे लागू करता है, जिसका सार इस कोड के टुकड़े द्वारा सबसे संक्षेप में व्यक्त किया जा सकता है:

var toobusy = require('toobusy'); app.use(function(req, res, next) { if (toobusy()) res.send(503, "I'm busy right now, sorry."); else next(); }); 

क्या समस्या है?

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

यह एक दुर्भावनापूर्ण वृद्धि हो सकती है, उदाहरण के लिए DoS हमले से। ऐसे हमलों से निपटने के लिए पहला कदम एक सर्वर लिखना है जो दुर्घटनाग्रस्त नहीं होता है।

आपका सर्वर लोड में है

यह दिखाने के लिए कि कैसे एक सामान्य सर्वर, उपस्थिति में वृद्धि के लिए तैयार नहीं है, व्यवहार करता है, मैंने एक डेमो एप्लिकेशन लिखा है जो प्रत्येक अनुरोध के लिए पांच अतुल्यकालिक कॉल करता है, कुल पांच मिलीसेकंड प्रोसेसर समय खर्च करता है।

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



इस डेटा का विश्लेषण काफी स्पष्ट है:

• सर्वर को उत्तरदायी नहीं कहा जा सकता है। एक लोड के तहत जो मानक भार (प्रति सेकंड 1200 अनुरोध) से छह गुना अधिक है, यह 40 सेकंड के बाद एक औसत प्रतिक्रिया के साथ एक क्रेक देता है।
• विफलताएं भयानक लगती हैं। 80% मामलों में, उपयोगकर्ता को लगभग एक मिनट के थकाऊ इंतजार के बाद एक त्रुटि संदेश मिलता है।

विनम्रता से मना करना सीखना

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



ग्राफ कोड 503 ( सेवा अनुपलब्ध ) के साथ त्रुटियों की संख्या नहीं दिखाता है - यह धीरे-धीरे बढ़ते भार के साथ बढ़ता है। इस ग्राफ को देखकर क्या निष्कर्ष निकाला जा सकता है?

• फॉरवर्ड एरर मैसेज विश्वसनीयता को जोड़ते हैं। मानक लोड से दस गुना अधिक लोड के तहत, एप्लिकेशन काफी जिम्मेदारी से व्यवहार करता है।
• एक सफल प्रतिक्रिया या विफलता जल्दी से होती है। औसत प्रतिक्रिया समय लगभग हमेशा 10 सेकंड से कम होता है।
• असफलता विनम्रता से होती है। भीड़ के दौरान अग्रिम अनुरोध को अस्वीकार करते हुए, हम 503 मिनट की त्रुटि के साथ एक त्वरित प्रतिक्रिया के साथ अजीब समय-बाहर गिरने की जगह लेते हैं।

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

नोड-टुबॉसी का उपयोग कैसे करें

नोड-थोबसी मॉड्यूल एनपीएम पैकेज और जीथब पर उपलब्ध है। स्थापना के बाद ( npm install toobusy ), यह आमतौर पर आवेदन में शामिल होता है:

 var toobusy = require('toobusy'); 

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

 //      middleware,  //    ,       -  app.use(function(req, res, next) { //    -  toobusy()  , //         if (toobusy()) res.send(503, "I'm busy right now, sorry."); else next(); }); 

पहले से ही इस रूप में, नोड-टोबुसी मॉड्यूल लोड के तहत आवेदन की स्थिरता में काफी वृद्धि करता है। यह संवेदनशीलता मूल्य का चयन करने के लिए बनी हुई है जो आपके आवेदन के लिए सबसे उपयुक्त है।

यह कैसे काम करता है?

आप कैसे विश्वास कर सकते हैं कि एक नोड आवेदन बहुत व्यस्त है?

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

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

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

हमें ऐसे समाधान की जरूरत है जो सिर्फ काम करे। हमें केवल यह निर्धारित करने की आवश्यकता है कि हमारा आवेदन स्वीकार्य दर पर अनुरोधों का जवाब देने में असमर्थ है। यह मानदंड प्लेटफ़ॉर्म या सिस्टम में अन्य प्रक्रियाओं पर निर्भर नहीं करता है।

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

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

---