6 पाठ Node.js सेवा प्रदर्शन अनुकूलन अनुभव से सीखे

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



Klarna Node.js. प्लेटफ़ॉर्म का उपयोग करता है लेख, जिसका अनुवाद आज हम प्रकाशित करते हैं, उन पाठों के लिए समर्पित है जो कंपनी के विशेषज्ञ अपनी सेवा के प्रदर्शन को अनुकूलित करने के अनुभव से सीखने में कामयाब रहे।

पाठ संख्या 1: प्रदर्शन परीक्षण यह विश्वास दिला सकता है कि सिस्टम की गति प्रत्येक रिलीज़ के साथ ख़राब नहीं होती है

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

पाठ संख्या 2: स्वतंत्र रूप से "वाइंडिंग" लोड, आप उत्पादन तक पहुंचने से पहले ही समस्याओं की पहचान कर सकते हैं

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


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

हमने फैसला किया, हालांकि यह अभी तक उत्पादन में नहीं हुआ था, कि यह केवल समय की बात थी। यदि वास्तविक भार एक निश्चित स्तर तक पहुँच जाता है, तो हम कुछ इसी तरह भाग सकते हैं। इसलिए, यह निर्णय लिया गया कि इस मुद्दे की जांच की जानी चाहिए।

पाठ संख्या 3: दीर्घकालिक तनाव परीक्षण विभिन्न समस्याओं की पहचान कर सकता है। यदि सब कुछ अच्छा लगता है, तो परीक्षण अवधि बढ़ाने का प्रयास करें।

ध्यान देने योग्य एक और बात यह है कि हमारे सिस्टम की समस्याएं लोड के तहत 2-3 मिनट के काम के बाद दिखाई देती हैं। सबसे पहले, हमने केवल 2 मिनट के लिए परीक्षण चलाया। और समस्या केवल तब देखी गई जब परीक्षण निष्पादन का समय 10 मिनट तक बढ़ा दिया गया।

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

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

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

एक अन्य संसाधन जो Node.js परियोजनाओं के प्रदर्शन को निर्धारित करता है, वह ईवेंट लूप है। जिस तरह हमारे लिए यह जानना महत्वपूर्ण है कि किसी प्रक्रिया द्वारा कितनी मेमोरी का उपयोग किया जाता है, हमें एक इवेंट लूप को संसाधित करने के लिए कितने "कार्यों" की आवश्यकता है। Node.js ईवेंट लूप C ++ लिब्युव लाइब्रेरी में लागू किया गया है ( यहां इसके बारे में एक अच्छा वीडियो है)। "कार्य" को "सक्रिय अनुरोध" के रूप में यहां संदर्भित किया गया है। एक अन्य महत्वपूर्ण मीट्रिक "सक्रिय हैंडल" की संख्या है जो कि Node.s प्रक्रिया द्वारा उपयोग की जाने वाली ओपन फ़ाइल डिस्क्रिप्टर या सॉकेट द्वारा दर्शाई जाती है। वर्णनकर्ता प्रकारों की एक पूरी सूची लिबव प्रलेखन में पाई जा सकती है। नतीजतन, यदि परीक्षण 30 कनेक्शन का उपयोग करता है, तो यह उम्मीद की जा सकती है कि सिस्टम में 30 सक्रिय विवरण होंगे। सक्रिय अनुरोधों की संख्या को इंगित करने वाला संकेतक किसी विशेष विवरणक के लिए कतार में प्रतीक्षा कर रहे ऑपरेशन की संख्या को इंगित करता है। ये ऑपरेशन क्या हैं? उदाहरण के लिए, संचालन पढ़ें / लिखें। इनकी पूरी सूची यहां पाई जा सकती है ।

सर्विस मेट्रिक्स का विश्लेषण करने के बाद, हमने महसूस किया कि यहां कुछ गलत था। जबकि सक्रिय विवरणकों की संख्या हमसे अपेक्षित थी (इस परीक्षण में - लगभग 30), सक्रिय अनुरोधों की संख्या बहुत अधिक थी - कई हजारों।


सक्रिय डिस्क्रिप्टर्स और सक्रिय अनुरोध

सच है, हमें अभी तक पता नहीं था कि कतार में किस प्रकार के अनुरोध थे। हमने सक्रिय प्रश्नों को प्रकारों में विभाजित करने के बाद, स्थिति थोड़ी साफ कर दी। अर्थात्, UV_GETADDRINFO क्वेरी बहुत ही ध्यान देने योग्य हैं। वे उत्पन्न होते हैं जब Node.js DNS नाम को हल करने का प्रयास करते हैं।

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

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


अनुरोध को संसाधित करने के लिए आवश्यक समय के बारे में जानकारी। बाहरी DNS कैश का उपयोग करने का परिणाम

पाठ # 5: बैच मोड में I / O संचालन करें। इस तरह के ऑपरेशन, यहां तक ​​कि अतुल्यकालिक, गंभीर संसाधन उपभोक्ता हैं।

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


अनुरोध को संसाधित करने के लिए आवश्यक समय के बारे में जानकारी। परीक्षण ने उत्तर के गठन के लिए आवश्यक समय में तेज वृद्धि का खुलासा किया

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


कफका के लिए संदेश उत्पन्न करने के लिए आवश्यक समय के बारे में जानकारी

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


अनुरोध को संसाधित करने के लिए आवश्यक समय के बारे में जानकारी। बैच संदेश प्रसंस्करण के आयोजन के बाद सुधार

पाठ संख्या 6: इससे पहले कि आप सिस्टम में कोई सुधार करने की कोशिश करें, परीक्षण तैयार करें, जिसके परिणामों पर भरोसा किया जा सकता है

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

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

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

परीक्षण के तहत सेवा Datalog में माप जानकारी प्रदान करता है। यह जानकारी एक उज्ज्वल पृष्ठभूमि के साथ ग्राफ़ के साथ यहां प्रस्तुत की गई है।

प्रिय पाठकों! क्या Node.js सेवा परीक्षण प्रणाली का उपयोग करते हैं?