Node.js में लगभग 30x कॉनसेरिटि बूस्ट

उत्पादन में उपयोग की जाने वाली Node.js सेवा में संक्षिप्त रूप से वृद्धि करने का सबसे अच्छा तरीका क्या है? यह एक ऐसा सवाल है जो मेरी टीम को कुछ महीने पहले जवाब देने के लिए चाहिए था।

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



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

यह सामग्री इस कहानी के लिए समर्पित है कि कैसे हमने अपने Node.js श्रमिकों की उत्पादकता और प्रभावशीलता को बढ़ाया, और इस तरह से जाकर हमने जो कुछ भी सीखा।

हमने समानता में निवेश करने का फैसला क्यों किया?

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

यद्यपि यह समझौता योजना लंबे समय से काम कर रही थी, लेकिन इसमें कई अप्रिय क्षणों को प्रकट करना संभव था। हम जानते थे कि वे, अंत में सेवा की विश्वसनीयता पर प्रतिकूल प्रभाव डाल सकते हैं।

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

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

हमने विश्वसनीयता का ख्याल रखते हुए अपडेट कैसे पेश किए

▍टूल और मॉनिटरिंग

हमारे पास अपना स्वयं का लोड बैलेंसर है, जो Node.js कार्यकर्ताओं के अनुरोधों को पुनर्निर्देशित करता है। प्रत्येक कार्यकर्ता अनुरोधों को संसाधित करने के लिए उपयोग किया जाने वाला एक जीआरपीसी सर्वर चलाता है। वर्कर रेडिस का उपयोग लोड बैलेंसर को बताने के लिए करता है कि वह उपलब्ध है। इसका मतलब यह है कि सिस्टम में समानता को जोड़ने से कोड की कुछ लाइनों को बदलने में कमी आती है। अर्थात्, कार्यकर्ता, अनुरोध किए जाने के बाद दुर्गम बनने के बजाय, उसे सूचित करना चाहिए कि वह तब तक उपलब्ध है जब तक कि वह उसके पास आए एन अनुरोधों को संसाधित करने में व्यस्त न हो जाए (उनमें से प्रत्येक अपने स्वयं के वादे वस्तु द्वारा प्रस्तुत)।

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

इन जोखिमों को कम करने के लिए, हम, पहले समानांतर कर्मचारी के उत्पादन में आने से पहले, सिस्टम में निम्नलिखित निगरानी उपकरणों और उपकरणों की उपलब्धता सुनिश्चित करते हैं:

• हमारे द्वारा पहले से इस्तेमाल की गई ईएलके स्टैक ने हमें पर्याप्त मात्रा में लॉग इन जानकारी प्रदान की है, जो सिस्टम में क्या हो रहा है, यह पता लगाने के लिए उपयोगी हो सकता है।
• हमने सिस्टम में कई प्रोमेथियस मैट्रिक्स जोड़े हैं। निम्नलिखित शामिल हैं:
  
  
  • V8 हीप का आकार process.memoryUsage() का उपयोग करके प्राप्त किया गया।
  • जीसी-सांख्यिकी पैकेज का उपयोग करके कचरा संग्रहण संचालन के बारे में जानकारी।
  • कार्यों को पूरा करने के लिए समय पर डेटा, बैंकों के साथ एकीकरण से संबंधित कार्यों के प्रकार और समूहीकरण के स्तर से समूहीकृत। हमें इस बात की आवश्यकता है कि यह सुनिश्चित करने के लिए कि कैसे संगणना प्रणाली प्रवाह को प्रभावित करता है
• हमने ग्रेफाना कंट्रोल पैनल बनाया, जिसे सिस्टम पर कंसीडर के प्रभाव की डिग्री का अध्ययन करने के लिए डिज़ाइन किया गया है।
• हमारे लिए, सेवा को फिर से तैयार करने की आवश्यकता के बिना आवेदन के व्यवहार को बदलने की क्षमता बेहद महत्वपूर्ण थी। इसलिए, हमने विभिन्न मापदंडों को नियंत्रित करने के लिए डिज़ाइन किए गए LaunchDarkly झंडे का एक सेट बनाया। इस दृष्टिकोण के साथ, श्रमिकों के मापदंडों का चयन, गणना की गई ताकि वे समानता के अधिकतम स्तर तक पहुंच सकें, हमें प्रयोगों को जल्दी करने और सर्वोत्तम मापदंडों को खोजने की अनुमति दी, इस पर कुछ मिनट बिताए।
• यह पता लगाने के लिए कि एप्लिकेशन के विभिन्न भाग प्रोसेसर को कैसे लोड करते हैं, हमने उत्पादन सेवा डेटा संग्रह उपकरण में बनाया है, जिसके आधार पर लौ आरेख बनाए गए थे।
  
  
  • हमने 0x पैकेज का उपयोग किया क्योंकि Node.js टूल को हमारी सेवा में एकीकृत करना आसान था, और क्योंकि अंतिम HTML डेटा विज़ुअलाइज़ेशन ने खोज का समर्थन किया और हमें अच्छे स्तर का विवरण दिया।
  • हमने सिस्टम में एक प्रोफाइलिंग मोड जोड़ा जब वर्कर ने 0x पैकेज को चालू किया और बाहर निकलते समय S3 में अंतिम डेटा लिखा। फिर हम S3 से उन लॉग को डाउनलोड कर सकते हैं और उन्हें स्थानीय रूप से 0x --visualize-only ./flamegraph की कमांड का उपयोग करके देख सकते हैं।
  • हमने, एक निश्चित समय में, केवल एक कार्यकर्ता के लिए प्रोफाइलिंग शुरू की। प्रोफाइलिंग से संसाधन की खपत बढ़ जाती है और उत्पादकता कम हो जाती है, इसलिए हम इन नकारात्मक प्रभावों को एक श्रमिक तक सीमित करना चाहेंगे।

Loyment तैनाती शुरू करें

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

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

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

विस्तृत करें, अन्वेषण करें, दोहराएं

J Node.js का अधिकतम ढेर आकार बढ़ाना

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

 FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - Javascript heap out of memory 1: node::Abort() 2: node::FatalException(v8::Isolate*, v8::Local, v8::Local) 3: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) 4: v8::internal::Factory::NewFixedArray(int, v8::internal::PretenureFlag) 

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

हमने सुझाव दिया कि Node.js हीप के अधिकतम आकार को बढ़ाकर, जो डिफ़ॉल्ट रूप से 1.7 GB पर सेट है, इस समस्या को हल करने में मदद कर सकता है। फिर हमने Node.js को चलाना शुरू किया, अधिकतम हीप आकार को 6 GB पर सेट करना (कमांड लाइन ध्वज का उपयोग करना --max-old-space-size=6144 )। यह सबसे बड़ा मूल्य था जो हमारे EC2 उदाहरणों के लिए उपयुक्त था। हमारी खुशी के लिए, इस तरह के एक कदम ने हमें उत्पादन में होने वाली उपरोक्त त्रुटि से निपटने की अनुमति दी।

▍ मेमोरी टोंटी पहचान

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


ढेर का उपयोग

इस ग्राफ के कुछ घटता लगातार बढ़ते गए - जब तक वे मुड़ नहीं गए, अधिकतम हीप आकार के स्तर पर, लगभग क्षैतिज रेखाओं में। हम वास्तव में इसे पसंद नहीं करते थे।

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

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

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

 const postTaskDebugging = async (data: TypedData) => {    const payload = await generateDebuggingPayload(data);       //       ,    //        .    // tslint:disable-next-line:no-floating-promises    compressAndUploadDebuggingPayload(payload)        .catch((err) => logger.error('failed to upload data', err)); } 

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


PostTaskDebugging को अक्षम करने के बाद हीप का उपयोग करना

यह निकला! अब समानांतर श्रमिकों में ढेर उपयोग स्तर लंबे समय तक स्थिर रहता है।

एक भावना थी कि सिस्टम में, जैसे-जैसे कार्य पूरे होते गए, वैसे-वैसे compressAndUploadDebuggingPayload लोड के "ऋण" धीरे-धीरे जमा होते गए। यदि कार्यकर्ता को इन "ऋणों" का "भुगतान" करने में सक्षम होने की तुलना में तेजी से कार्य प्राप्त हुए, तो जिन वस्तुओं के तहत मेमोरी आवंटित की गई थी, वे कचरा संग्रहण कार्यों के अधीन नहीं थे। इससे ढेर को बहुत ऊपर तक भरने में मदद मिली, जिसे हमने ऊपर माना, पिछले चार्ट का विश्लेषण किया।

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

यह तय करने के बाद कि हम इस समस्या के समाधान को अंतिम उपाय के रूप में उपयोग करेंगे, हमने कोड को अनुकूलित करने के बारे में सोचना शुरू किया। इस ऑपरेशन को गति कैसे दें?

▍फिक्स टोंटी S3

compressAndUploadDebuggingPayload तर्क यह पता लगाना आसान है। यहां हम डिबग डेटा को संपीड़ित करते हैं, और यह काफी बड़ा हो सकता है, क्योंकि इसमें नेटवर्क ट्रैफ़िक शामिल है। फिर हम संपीड़ित डेटा को S3 पर अपलोड करते हैं।

 export const compressAndUploadDebuggingPayload = async (    logger: Logger,    data: any, ) => {    const compressionStart = Date.now();    const base64CompressedData = await streamToString(        bfj.streamify(data)            .pipe(zlib.createDeflate())            .pipe(new b64.Encoder()),    );    logger.trace('finished compressing data', {        compression_time_ms: Date.now() - compressionStart,    );           const uploadStart = Date.now();    s3Client.upload({        Body: base64CompressedData,        Bucket: bucket,        Key: key,    });    logger.trace('finished uploading data', {        upload_time_ms: Date.now() - uploadStart,    ); } 

किबाना लॉग से, यह स्पष्ट था कि एस 3 में डेटा डाउनलोड करना, भले ही इसकी मात्रा छोटी हो, बहुत समय लगता है। हमने शुरू में यह नहीं सोचा था कि सिस्टम में सॉकेट्स एक अड़चन बन सकते हैं, क्योंकि मानक Node.js HTTPS एजेंट, Infinity को मैक्सिमम पॉकेट पैरामीटर सेट करता है। हालाँकि, अंत में, हमने maxSockets पर AWS के डॉक्यूमेंट को पढ़ा और हमारे लिए कुछ आश्चर्यजनक पाया: S3 क्लाइंट ने maxSockets पैरामीटर के मान को maxSockets 50 । कहने की जरूरत नहीं है, इस व्यवहार को सहज नहीं कहा जा सकता है।

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

 const s3Client = new AWS.S3({    httpOptions: {        agent: new https.Agent({            //                 //          S3.            maxSockets: 1024 * 20,        }),    },    region, }); 

Serial JSON क्रमांकन को गति देना

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

डेटा संपीड़न में तीन चरण होते हैं (यहां, मेमोरी उपयोग को सीमित करने के लिए, Node.js स्ट्रीम का उपयोग किया जाता है)। अर्थात्, पहले चरण में, स्ट्रिंग JSON डेटा उत्पन्न होता है, दूसरे में, डेटा को zlib का उपयोग करके संपीड़ित किया जाता है, तीसरे में, इसे बेस 64 एन्कोडिंग में बदल दिया जाता है। हमें संदेह था कि जिन समस्याओं का स्रोत हम JSON तार - bfj उत्पन्न करने के लिए उपयोग करते हैं वे तृतीय-पक्ष लाइब्रेरी हो सकते हैं। हमने एक स्क्रिप्ट लिखी थी जो धाराओं का उपयोग करके JSON स्ट्रिंग डेटा उत्पन्न करने के लिए विभिन्न पुस्तकालयों के प्रदर्शन की जांच करती है (इसी कोड को यहां पाया जा सकता है )। यह पता चला कि बिग फ्रेंडली JSON पैकेज जो हम उपयोग कर रहे थे, वह बिल्कुल भी अनुकूल नहीं था। प्रयोग के दौरान प्राप्त माप के कुछ परिणामों को देखें:

 benchBFJ*100:    67652.616ms benchJSONStream*100: 14094.825ms 

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

। कचरा संग्रहण के लिए आवश्यक समय को कम करना

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


पारंपरिक और समानांतर श्रमिकों द्वारा कार्यों के निष्पादन समय का अनुपात

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

विशेष रूप से, हमारा ध्यान --nouse-idle-notification ध्वज के उपयोग के लिए आकर्षित किया गया था। क्या हमारी Node.js प्रक्रियाएं कचरा इकट्ठा करने में इतना समय लगा सकती हैं? यहाँ, जीसी-स्टैटिस्टिक्स पैकेज ने हमें कचरा संग्रहण पर बिताए औसत समय को देखने का अवसर दिया।


कचरा संग्रह पर बिताए समय का विश्लेषण

एक भावना थी कि हमारी प्रक्रियाओं ने स्कैवेंज एल्गोरिथ्म का उपयोग करके कचरा इकट्ठा करने में लगभग 30% समय व्यतीत किया। यहाँ हम Node.js. में विभिन्न प्रकार के कचरा संग्रहण के बारे में तकनीकी विवरणों का वर्णन नहीं करेंगे। यदि आप इस विषय में रुचि रखते हैं - इस सामग्री पर एक नज़र डालें। स्केवेंज एल्गोरिथ्म का सार यह है कि कचरा संग्रह को अक्सर "नई जगह" नामक Node.js ढेर में छोटी वस्तुओं द्वारा कब्जा की गई मेमोरी को खाली करने के लिए शुरू किया जाता है।

इसलिए, यह पता चला है कि हमारे नोड्स में कचरा संग्रहण की प्रक्रिया बहुत बार शुरू होती है। क्या मैं V8 कचरा संग्रह को अक्षम कर सकता हूं और इसे स्वयं चला सकता हूं? क्या कचरा संग्रह कॉल की आवृत्ति को कम करने का एक तरीका है? यह पता चला कि उपरोक्त में से पहला नहीं किया जा सकता है, लेकिन अंतिम - यह संभव है! हम बस कमांड लाइन फ्लैग --max-semi-space-size=1024 का उपयोग करके Node.js में "सेमी स्पेस" क्षेत्र की सीमा को बढ़ाकर "नई जगह" क्षेत्र का आकार बढ़ा सकते हैं। यह आपको V8 कचरा संग्रहण शुरू होने तक अल्पकालिक वस्तुओं के लिए अधिक मेमोरी आवंटन संचालन करने की अनुमति देता है। नतीजतन, ऐसे ऑपरेशन लॉन्च करने की आवृत्ति कम हो जाती है।


कचरा संग्रहण अनुकूलन परिणाम

एक और जीत! "नई जगह" क्षेत्र में वृद्धि ने स्केवेंज एल्गोरिथ्म का उपयोग करते हुए कचरा संग्रह पर बिताए समय की मात्रा में उल्लेखनीय कमी का कारण बना - 30% से 2% तक।

Ptऑप्टिमाइज़ प्रोसेसर प्रोसेसर का उपयोग

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

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


0x उपकरण के साथ डेटा विश्लेषण

स्तंभों में हाइलाइट किए गए नीले-हरे क्षेत्रों से संकेत मिलता है कि कम से कम 15% प्रोसेसर समय कार्यकर्ता लॉग बनाने में खर्च किया गया था। नतीजतन, हम इस समय को 75% तक कम करने में सक्षम थे। यह सच है कि हमने यह कैसे किया, इसकी कहानी एक अलग लेख है। (संकेत: हमने नियमित अभिव्यक्ति का उपयोग किया और गुणों के साथ बहुत काम किया)।

इस अनुकूलन के बाद, हम सिस्टम के प्रदर्शन को नुकसान पहुंचाए बिना एक कार्यकर्ता में 30 कार्यों को एक साथ करने में सक्षम थे।

परिणाम

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

बैंकों के साथ हमारी एकीकरण सेवा को समानांतर करते हुए, हमने बहुत सी नई चीजें सीखीं:

• कभी भी निम्न-स्तरीय सिस्टम मेट्रिक्स होने के महत्व को कम मत समझो। कचरा संग्रहण और स्मृति उपयोग से संबंधित डेटा की निगरानी करने की क्षमता ने हमें सिस्टम को तैनात करने और इसे अंतिम रूप देने में जबरदस्त सहायता प्रदान की है।
• ज्वलंत ग्राफिक्स एक महान उपकरण हैं। अब जब हमने सीखा कि उनका उपयोग कैसे किया जाए, तो हम उनकी मदद से सिस्टम में नई अड़चनों को आसानी से पहचान सकते हैं।
• Node.js रनटाइम तंत्र को समझने से हमें बेहतर कोड लिखने की अनुमति मिली। उदाहरण के लिए, यह जानते हुए कि वी 8 वस्तुओं के लिए स्मृति कैसे आवंटित करता है, और कचरा संग्रह कैसे काम करता है, हमने वस्तुओं का पुन: उपयोग तकनीक का व्यापक रूप से उपयोग करने में बिंदु को देखा। कभी-कभी यह सब समझने के लिए, आपको सीधे V8 के साथ काम करने या Node.js. कमांड लाइन के झंडे के साथ प्रयोग करने की आवश्यकता है।
• , . maxSocket , Node.js, , , , AWS Node.js . , , , .

प्रिय पाठकों! Node.js-?