एक नोड के पुराने और नए संस्करणों के प्रदर्शन के मुद्दे पर

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

शुरू करने से पहले, मैं आपको आईटी व्यवसाय का मूल सिद्धांत याद दिलाता हूं: कार्य करें, न करें!

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

मेरा लेख उन लोगों के लिए है जिनकी अभी भी आवश्यकता है। मैं अपनी हाल की स्थिति का वर्णन करूंगा, इसे हल करने में आने वाली कठिनाइयों के बारे में बात करूंगा, और उन परिणामों को दूंगा जो मुझे अंततः प्राप्त हुए थे।

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

आप क्या सामना कर रहे हैं?

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

समस्या एक:

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

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

दूसरी समस्या:

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

मैंने इंटरनेट पर विभिन्न स्थानों में यह पूछने की कोशिश की कि नोड के मेमोरी प्रबंधन कैसे करें और हमारी स्थिति को कैसे हल करें। लेकिन जवाब में, मुझे 0.10 नोड के उपयोग के बारे में केवल नकारात्मकता प्राप्त हुई। सामान्य तौर पर, यह यह नकारात्मकता थी जो मुझे नोड के नवीनतम संस्करणों पर स्विच करने के कार्य में ले गई।

क्या वापस पकड़ रहा था?

1. उत्पादकता के नुकसान का डर।

अजगर पर काम करने वालों को याद है कि 2.x से 3.x लाइन तक संक्रमण उत्पादकता के पर्याप्त नुकसान के साथ था। मुझे नहीं पता कि चीजें अब अजगर में कैसे हैं, शायद स्थिति में सुधार हुआ है। लेकिन यह उम्मीद करना काफी तर्कसंगत है कि इन सभी नई सुविधाओं को es6 में जोड़ने के बाद, नोड भी ठोस रूप से डूब सकता है। मैंने पुराने लोगों के साथ नए नोड्स की तुलना करने के लिए कुछ बेंचमार्क को गूगल करने की कोशिश की, मुझे कुछ भी समझदार नहीं मिला।

2. प्रदर्शन JSON.parse

जब से हम लॉग के साथ काम करते हैं, JSON.parse प्रोसेसर के शेर के हिस्से पर कब्जा कर लेता है। एक समय में, हमने नोड के विभिन्न संस्करणों पर इसकी तुलना की और लगभग 30% का प्रदर्शन गिरा दिया। 4.x नोड की तुलना 0.10 और 0.12 से की गई थी।

वास्तव में, ये कारण निर्णायक नहीं थे, क्योंकि प्रोसेसर एक अड़चन नहीं था। इसके अलावा, ऐसे कार्यों के लिए क्षैतिज स्केलिंग है।

3. पैकेज निर्भरता

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

क्या दिया?

नतीजतन, हम अभी भी नोड 0.10 से अंतिम लेट्स 8.11.x पर चले गए

1. कोई प्रदर्शन ड्रॉप नहीं। इसके विपरीत, हमें 10-15% के ऑर्डर की वृद्धि प्राप्त हुई
2. घटक के आधार पर, लगभग 30-50% स्मृति की खपत में सुधार हुआ है
3. "अनसुलझी" समस्याओं को स्वयं द्वारा सुलझाया गया
4. हमें आखिरकार es6 से नई सुविधाओं का उपयोग करने का अवसर मिला! हालाँकि आदत से बाहर, हम अभी भी उनका उपयोग नहीं करते हैं)))