नोड.जेएस आवेदन का अनुकूलन

दिया गया: पुराना http नोड.जेएस एप्लिकेशन और उस पर लोड बढ़ा हुआ।

समस्या के मानक समाधान: सर्वर से बाहर निकलें, 0 से सब कुछ फिर से लिखें, जो पहले से लिखा गया है उसे अनुकूलित करें।

आइए अनुकूलन के माध्यम से जाने की कोशिश करें और यह पता लगाएं कि आवेदन की कमजोरियों को कैसे ढूंढें और सुधारें। और शायद कोड की एक भी लाइन को छूने के बिना तेजी लाने के :)

बिल्ली के नीचे सभी इच्छुक स्वागत करते हैं!

सबसे पहले, एक प्रदर्शन परीक्षण तकनीक पर निर्णय लेते हैं। हम 1 सेकंड: आरपीएस में दिए गए अनुरोधों की संख्या में रुचि लेंगे।

हम कार्यकर्ता के मोड 1 में आवेदन को चलाएंगे (1 प्रक्रिया), पुराने कोड के प्रदर्शन को मापने और अनुकूलन के साथ कोड - पूर्ण प्रदर्शन महत्वपूर्ण नहीं है, तुलनात्मक प्रदर्शन महत्वपूर्ण है।

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

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

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

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

बेचे गए सर्वर नोड 6 संस्करण का उपयोग करते हैं - चलो इसके साथ शुरू करते हैं:

अनुरोध / सेकंड: 1210

हम 8 वें नोड पर कोशिश करते हैं:
अनुरोध / सेकंड: 2308
10 वां नोट:
अनुरोध / सेकंड: 2590

अंतर स्पष्ट है। यहां महत्वपूर्ण भूमिका v8 संस्करण को अपडेट करके निभाई गई है - अतीत में बहुत खराब रूप से अनुकूलित v8 कोड है। और नोड.जेएस वी 8 में गायब होने वाली पवनचक्कियों से निपटने के क्रम में, तुरंत अपग्रेड करना बेहतर है, और फिर कोड अनुकूलन करना।

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

परिक्षण से पहले परीक्षण कोड का फ्लेमोग्राफ कुछ इस तरह दिखता है:


फ़िल्टर के नीचे, ऐप छोड़ दें, डिपो - केवल एप्लिकेशन और तृतीय-पक्ष मॉड्यूल का कोड।

चौड़ी पट्टी, इस फ़ंक्शन को निष्पादित करने में अधिक समय व्यतीत होता है (नेस्टेड कॉल सहित)।

हम केंद्रीय, सबसे बड़े हिस्से से निपटेंगे।

सबसे पहले, हम गैर-अनुकूलित कार्यों को उजागर करते हैं। मैंने आवेदन में इनमें से कुछ पाया।

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

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

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

इसलिए, हम केवल शुरुआती फ़ंक्शन छोड़ते हैं, हमें मिलता है:

अनुरोध / सेकंड: 16176



कोर, वी 8 फिल्टर को कनेक्ट करके, आप देख सकते हैं कि जांच के तहत लगभग पूरे फ़ंक्शन में एक उत्तर भेजने, लॉगिंग और अन्य खराब अनुकूलित चीजों के होते हैं - हम आगे बढ़ते हैं।

हम निम्न फ़ंक्शन से गुजरते हैं:

अनुरोध / सेकंड: 16111
कुछ भी नहीं बदला है - आगे आगे बढ़ें:
अनुरोध / सेकंड: 13330


हमारे ग्राहक! यह देखा जा सकता है कि getByUrl फ़ंक्शन शामिल है, जो फ़ंक्शन फ़ंक्शन के एक महत्वपूर्ण हिस्से पर कब्जा कर लेता है - जो कि रस्मी सबसिडी के साथ अच्छी तरह से संबंध रखता है।

हम ध्यान से देखते हैं कि इसमें क्या हो रहा है (कोर, v8 चालू करें):

बहुत सारी चीजें हो रही हैं ... हम कोड धूम्रपान करते हैं, अनुकूलन करें:

for (var i in this.data) { if (this[i]._options.regexp_obj.test(url)) return this[i]; } return null; 

में बदल जाते हैं

 let result = null; for (let i=0; i<this.length && !result; i++) { if (this[i]._options.regexp_obj.test(url)) result = this[i]; } 

इस मामले में, for..in की तुलना में एक सरल बहुत तेज है

अनुरोध / सेकंड प्राप्त करें : 16015



विज़ुअली, फ़ंक्शन "डिफ्लेट" हो जाता है और शुरुआती फ़ंक्शन के बहुत छोटे हिस्से पर कब्जा कर लेता है।
समारोह में विस्तृत जानकारी में, सब कुछ बहुत सरल किया गया था:

हम अगले फ़ंक्शन पर जाते हैं।

अनुरोध / सेकंड: 13316



इस फ़ंक्शन में बहुत सारे सरणी फ़ंक्शन हैं और नोड के हाल के संस्करणों में महत्वपूर्ण त्वरण के बावजूद, वे अभी भी सरल छोरों की तुलना में धीमे हैं: परिवर्तन [] .map और फ़िल्टर। और पाने के लिए नियमित रूप से

अनुरोध / सेकंड: 15067



और इसलिए समय के बाद, प्रत्येक बाद के कार्य के लिए।

कुछ और उपयोगी अनुकूलन: कुंजी के गतिशील रूप से बदलते सेट के साथ हैश के लिए, नया मानचित्र () नियमित {} की तुलना में 40% तेज हो सकता है;

Math.round (el * 100) / 100 ,Fixed (2) की तुलना में 2 गुना तेज है।

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

उदाहरण के लिए, कई इंडेक्सऑफ और प्रतिस्थापन कॉल के साथ विभाजन की जगह दोहरे प्रदर्शन लाभ दे सकती है।

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

नोड के आउटपुट का एक विचारशील अध्ययन --trace_file_names --trace_opt_verbose --trace-deopt --trace_opt यहां मदद कर सकता है।

उदाहरण के लिए, प्रपत्र की पंक्तियाँ

deoptimizing (DEOPT नरम): 0x2bcf38b2d079 शुरू करें <JS Function getTime ... बाइनरी ऑपरेशन के लिए अपर्याप्त प्रकार की प्रतिक्रिया के कारण लाइन का नेतृत्व किया गया

वापसी वैल> = 10 वैल: '0' + वैल;

के लिए प्रतिस्थापन

वापसी (val> = 10; '': '0') + val;

स्थिति को ठीक किया।

पुराने v8 इंजन के लिए कारणों और कार्यों को अपनाने के तरीकों की बहुत जानकारी है:

github.com/P0lip/v8-deoptimize-reasons - सूची,
www.netguru.co/blog/tracing-patterns-hinder-performance - विशिष्ट कारणों का विश्लेषण,
www.html5rocks.com/en/tutorials/speed/v8 - v8 के लिए अनुकूलन के बारे में, मुझे लगता है कि वर्तमान v8 इंजन के लिए भी यही सच है।

लेकिन कई समस्याएं अब नए v8 के लिए प्रासंगिक नहीं हैं।

वैसे भी, सभी अनुकूलन के बाद, मैं अनुरोध / सेकंड प्राप्त करने में कामयाब रहा: 9971 , अर्थात्। यह नोड के नवीनतम संस्करण में संक्रमण के कारण लगभग 2 गुना तेज हो जाएगा। कोड ऑप्टिमाइज़ेशन के कारण अन्य 4 बार।

मुझे उम्मीद है कि यह अनुभव किसी और के लिए उपयोगी होगा।