👩🏽‍🏫 💲 🧒🏾 सर्वर पर जावास्क्रिप्ट, प्रति परिवर्तन 1ms 🎻 🌀 🎦

क्यों?

सवाल "क्यों?" किसी भी निर्णय लेते समय सबसे महत्वपूर्ण है। हमारे मामले में, कई कारण थे।

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

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

लेकिन Mail.Ru Group के पास उच्च योग्य लोगों की एक पूरी टीम है जो JS को जानते हैं, अपने दम पर एक उपकरण लिखने में सक्षम हैं, और सबसे महत्वपूर्ण बात यह है कि वे इसका उपयोग करेंगे।

दूसरी बात, कार्य। प्रोजेक्ट Mail@Mail.ru को लें। हम सर्वर पर टेम्प्लेटिंग को मना नहीं कर सकते - हमें पहले लॉगिन पर तेज़ लोडिंग की आवश्यकता है। हम क्लाइंट पर मानकीकरण से मना नहीं कर सकते - लोगों को अपने कार्यों के लिए एक उच्च प्रतिक्रिया दर देखना चाहिए, जिसका अर्थ है कि ग्राहक पर AJAX और मानकीकरण की आवश्यकता है।

समस्या स्पष्ट है: सर्वर और क्लाइंट पर पूरी तरह से अलग टेम्पलेट्स के दो सेट। और सबसे अधिक आक्रामक यह है कि वे एक ही समस्या को हल करते हैं। तर्क की नकल ने हमें थका दिया।

v8 एक जावास्क्रिप्ट दुभाषिया है, जिसका अर्थ है कि हम एक टेम्पलेट प्राप्त कर सकते हैं जो सर्वर और क्लाइंट दोनों पर काम करता है।

तीसरी बात, गति। कई लेखों को पढ़ने के बाद जिसमें वे v8 की गति की प्रशंसा करते हैं, हमने फैसला किया कि हमें उनकी निष्पक्षता को सत्यापित करने की आवश्यकता है। लेकिन पहले आपको यह समझना था कि हम नए टेम्पलेट इंजन को कैसे देखना चाहते हैं।

क्या जरूरत है?

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

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

/head.xml … <title><fest:get name=”title”/></title> <fest:set name=”title”>Mail.ru</fest:set> /mail.xml … <fest:include src=”head.xml”/> <fest:set name=”title”> Mail.ru</fest:set>

V8 का उपयोग करना अजीब होगा और जावास्क्रिप्ट को टेम्प्लेट तक पहुंच नहीं देगा।

 <fest:script> var text = “mail.ru” </fest:script> <fest:value>text</fest:value>

और बहुत कुछ छोटी चीज़ों पर, मानक स्थितियों और चक्रों के अलावा।

एक्सएमएल

हमने टेम्पलेट इंजन के लिए सिंटैक्स के रूप में XML लिया।

आईडीई में बुनियादी कार्यक्षमता के लिए समर्थन। एक सौ प्रतिशत लोकप्रिय IDE जानते हैं कि XML क्या है। हाइफ़नेशन, बैकलाइटिंग, बेसिक ऑटो-कम्प्लीशन आपको मुफ्त में मिलता है।

IDE स्तर सत्यापन। मान्य HTML मान्य टेम्प्लेट के माध्यम से प्राप्त किया जाता है। फिर से, सभी IDE इस तरह से xml को मान्य कर सकते हैं।

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

ऑफ-द-शेल्फ उपकरण की एक विस्तृत श्रृंखला। वर्षों से, XML प्रसंस्करण के लिए कई उपकरण जमा हुए हैं, उदाहरण के लिए, XSL का उपयोग कर प्रसंस्करण के लिए पुस्तकालयों या सत्यापन के लिए SAX पार्सर, XSD और DTD योजनाओं की एक पूरी कक्षा आदि।

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

कार्यान्वयन

Kovboystvo। मैंने खुद हाल ही में सीखा है कि इस तरह का एक शब्द है।

इससे पहले, मुझे यकीन था कि कार्य को पूरा करने का सबसे विश्वसनीय तरीका जोड़ी प्रोग्रामिंग और परीक्षण था। टेस्ट, हमेशा की तरह, भुगतान किया, लेकिन युग्मन प्रोग्रामिंग को विकल्प मिला।

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

हमने दो अलग-अलग दृष्टिकोण चुने: उन्होंने टेम्पलेट को एक फंक्शन में संकलित किया, और मैंने एक संरचना में। सबसे सरल संरचना का एक उदाहरण:

 01 [ 02 {action:"template"}, 03 "<html>...", 04 {action:"value"}, 05 "json.value" 06 ]

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

 01 [ 02 {action:"template"}, 03 "<html>....”, 04 {action:"if"}, 05 "json.value", 06 "<span>true</span>", 07 "<span>false</span>" 08 ]

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

फ़ंक्शन के साथ विकल्प को विशेष रूप से समझाया जाने की आवश्यकता नहीं है।

 01 function template(json){ 02 var html = ""; 03 html += "<html>…"; 04 html += json.value; 05 return html; 07 }

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

यह समझने के लिए कि मैंने यह दृष्टिकोण क्या दिया: मेरे पहले कार्यान्वयन ने 200ms के लिए कार्य पूरा किया। जब हमने वह सबकुछ निचोड़ लिया जो संभव है, और फिर हमारे दो कार्यक्रमों में से सर्वश्रेष्ठ को मिला दिया, तो हमें 3ms मिले।

यदि हम वर्तमान कार्यान्वयन का संक्षेप में वर्णन करते हैं, तो हम चक्रों को चक्रों में रूपांतरित करते हैं, सशर्त बयानों को सशर्त विवरणों आदि में बदलते हैं।

 fest:foreach for(i = 0; i < l; i++) {} fest:if if(value) {} fest:choose if(value) {} else {}

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

यह महत्वपूर्ण है कि टेम्पलेट्स को जेएस फ़ंक्शन में अनुवादित किया जाता है जो सख्त मोड में काम करता है। यह कोडर्स को कोड लिखने का मौका नहीं देता है जिससे मेमोरी लीक हो जाएगी।

जहां भी आपको डेटा के साथ तार्किक कार्य की आवश्यकता होती है, जावास्क्रिप्ट उपलब्ध है।

 <fest:if test=”_javascript_”></fest:if> <fest:value>_javascript_</fest:value>

जावास्क्रिप्ट को शामिल करने वाले सभी निर्माण एक कोशिश में पकड़े जाते हैं।

सभी निर्माण जो जावास्क्रिप्ट को चलाने के बाद एचटीएमएल आउटपुट को मानते हैं, वे एचटीएमएल से बच जाएंगे।

 <fest:value>json.name</fest:value>

 try { html += __escape(json.name) } catch(e) {}

शुरुआत से ही, टेम्पलेट इंजन का विकास एक खुले रूप में किया गया है।
https://github.com/mailru/fest

एकीकरण विकल्प

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

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

और, ज़ाहिर है, प्रोटोटाइप और ब्राउज़र के लिए NodeJS ऐसे वातावरण हैं जहां जावास्क्रिप्ट टेम्पलेट बॉक्स से बाहर काम करते हैं।

मुकाबला करने की स्थिति के करीब

3ms प्राप्त करने के बाद, मैं सर्वर साइड प्रोग्रामर के पास गया। जब उनसे पूछा गया कि मेरे पास उपयोगकर्ता ईमेल की सूची भेजने वाले अनुरोध के लिए कितना समय है, तो उन्होंने कहा: 4ms से अधिक नहीं। मेरे पास परिवर्तन के लिए पहले से ही 3ms थे, मुझे कोशिश करनी थी।

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

ऐतिहासिक कारणों से, हमारा http सर्वर फ्लैट हैश में डेटा संग्रहीत करता है।

 msg_length = 5 msg_1_title = “letter” msg_1_Unread = 1

जब से हम जावास्क्रिप्ट के बारे में बात कर रहे हैं, पहली बात जो दिमाग में आती है वह JSON है

 msg = [ {title: “letter”, Unread: true} ]

हमने एक फ्लैट हैश के साथ एक लाइन ली, इसे मेमोरी में डाल दिया और परिणाम को प्राप्त करना शुरू कर दिया, जब टेम्पलेट को v8 में बदल दिया, जावास्क्रिप्ट ने JSON के साथ काम किया।

हम कई विकल्पों से गुजरे। ऑब्जेक्ट को अग्रेषित करें, स्ट्रिंग को अग्रेषित करें और इसे जावास्क्रिप्ट में पार्स करें, स्ट्रिंग को अग्रेषित करें और इसे JSON.parse के माध्यम से पास करें।

ताज्जुब है, यह JSON से मेल खाने वाले स्ट्रिंग को फ्लैट हैश में बदलने के लिए सबसे तेज़ निकला, और v8 को एक स्ट्रिंग देने के लिए

 “template([ {title: \“letter\”, Unread: true} ])”

लेकिन, सब कुछ के बावजूद, हम 2ms परिवर्तन के साथ 6ms में भाग गए। हर कोई हार मानने को तैयार था। फिर भी, मैंने स्रोत डेटा लेने का फैसला किया, एक फ्लैट हैश के साथ एक लाइन और, उसी संकलित टेम्पलेट का उपयोग करके, NodeJS में आवश्यक HTML प्राप्त करें।

4ms मिला। जब मैं इस नंबर के साथ हमारे सिशनिकोव में आया, तो मैंने ईमानदारी से वाक्यांश "कूल, लेकिन NodeJS" की अपेक्षा की, हमारे पास लिखने के लिए कोई संसाधन नहीं हैं "लेकिन इसके बजाय मैंने सुना" अगर नोड्स इसे 4ms में कर सकते हैं, तो हम भी कर सकते हैं! "।

यह उस क्षण था जब मुझे एहसास हुआ - हम इसे उत्पादन में लाएंगे। एक दूसरी हवा थी!

समाधान सरल था। चूंकि हम डेटा तैयार करने में अपना 67% समय गंवाते हैं, और सिद्धांत रूप में हमारे पास पहले से ही डेटा है, हमें डेटा तैयार करने की आवश्यकता है।

हमने v8 में __get ('कुंजी') फ़ंक्शन को फेंक दिया। इस प्रकार, हमने v8 से सीधे अपने http सर्वर के हैश से डेटा लिया। वांछित प्रारूप में कोई डेटा रूपांतरण नहीं। V8 के अंदर इस स्ट्रिंग का ऑब्जेक्ट में कोई रूपांतरण नहीं है। हमने 3ms पर छोड़ दिया और 1ms का रिजर्व था।

लगभग उत्पादन

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

हम एक अलग सर्वर लेते हैं, उस पर v8 के साथ काम करने वाले http सर्वर के संस्करण को बढ़ाते हैं, और इसके लिए वास्तविक अनुरोधों की नकल करते हैं। हम 30 घंटों के लिए 2.2 गीगाहर्ट्ज के एक कोर को छोड़ देते हैं।

 10,000,000+ हिट
 1.6ms औसत परिवर्तन समय

 2 और 5ms के बीच 992 422 10%
 5 और 10ms के बीच 208 464 2%
 39 649 0.4% 10ms से अधिक है

केवल 12% 2ms से अधिक थे। v8 स्मृति से कठोर व्यवहार करता है।

प्रोडक्शंस

मैं अंतिम आंकड़ों के साथ उप तकनीकी निदेशक के पास आया, यह कहते हुए कि v8 उत्पादन के लिए तैयार है, हमें एक अलग से छोटी परियोजना बनाने की जरूरत है, जो कि अगर कुछ भी हो, तो विफलता के मामले में उसे भुलाया जा सकता है। इसके जवाब में, उन्होंने कहा कि नंबर अच्छे हैं, एक अलग परियोजना है, जिसकी विफलता बहुत भयानक नहीं है, सही है, लेकिन क्या आप वास्तव में v8 लॉन्च करना चाहते हैं? Mail.Ru होमपेज से शुरू करें। ” सवाल सही ढंग से सामने आया है - या तो हम व्यापार कर रहे हैं, या फिर मौज मस्ती कर रहे हैं।

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

आगे मैं एक बहुत ही अच्छी कहानी के साथ एक शिक्षाप्रद कहानी बताऊंगा।

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

वे देखने लगे। यहां मैं मुख्य वास्तुकला के बारे में थोड़ी बात करूंगा। यह विभिन्न परियोजनाओं से जानकारी एकत्र करता है। इसके आंतरिक विकास को इकट्ठा करता है, हम इसे आरबी कहते हैं। 165kb में से जो मुख्य को लौटाने के लिए उत्पन्न होते हैं, 100kb RB एकत्र करता है। और निम्न होता है: V8 में http सर्वर के माध्यम से RB HTML टुकड़े भेजता है, v8 उन्हें अपने स्वयं के तार से समेटता है, और परिणाम http सर्वर पर यह सब वापस लौटता है।

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

 __push_string('foo'); __push_rb(id); __push_string('bar');

प्लस के रूप में, v8 पर कोई स्ट्रिंग समवर्ती नहीं है, सर्वर से v8 और इसके विपरीत में कोई डबल आरबी अग्रेषण नहीं है, और सबसे महत्वपूर्ण बात, कोई भी डेटा अग्रेषण utf-8 से utf-16 और इसके विपरीत में रूपांतरण है। V8 utf-16 में सब कुछ संग्रहीत करता है।

एक लाभ था, संसाधनों का दो बार सामान्य रूप से उपभोग किया गया था, और तीन नहीं। यानी हम अभी भी चार बार हार गए, हालांकि यह ड्रॉप करने के लिए सब कुछ निचोड़ने के लिए लग रहा था।

और अब शिक्षाप्रद हिस्सा। ब्याज की खातिर, मैंने लोड किया जो हमने परीक्षण किया, दो से गुणा किया, मशीन पर राक्षसों की संख्या और मशीनों की संख्या। 440 मिलियन हिट्स प्राप्त किए। इसके अलावा, हमारे पास प्रति दिन 110 मिलियन हिट हैं। अस्पष्ट शंकाओं में दरार है।

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

अगली सुबह, हमने v8 के साथ मुख्य पृष्ठ का एक संस्करण निकाला।

आज के लिए डेटा:
HTML का जो v8 जेनरेट करता है उसका आकार 65kb है।
समय, काम v8 प्रति अनुरोध 1ms।
औसतन, v8 को प्रति संदर्भ 40MB की आवश्यकता होती है।

स्पष्टीकरण के एक जोड़े

हर कोई जो v8 के बारे में सोचता है, वह इगोर सायसोव sysoev.ru/prog/v8.html के एक लेख में आया था

इस कार्य के लिए हर समय काम करने के लिए, v8 डेवलपर व्याचेस्लाव ईगोरोव (http://mrale.ph) ने हमारी बहुत मदद की।

याददाश्त का डर जायज है। यदि सही संचालन आपके लिए महत्वपूर्ण है (बशर्ते कि स्मृति की कमी एक नियमित स्थिति है), तो आपको समस्याएं होंगी। आप आवंटन त्रुटि को सही ढंग से पकड़ सकते हैं, लेकिन आप इसके बारे में सही तरीके से पुनः आरंभ करने के लिए कर सकते हैं।

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

यह पता चला कि हमारे पास v8 ट्रंक बह रहा है। व्याचेस्लाव इसे पुन: पेश नहीं कर सका, लेकिन, मुझे लगता है, हम एक परीक्षण मामले को एक साथ रखेंगे जो डेवलपर्स को एक रिसाव खोजने में मदद करेगा। संस्करण 3.6 स्मृति से ठीक व्यवहार करता है।

उपयोगी लिंक

- github.com/mailru/fest टेम्पलेट इंजन
- code.google.com/p/v8 v8 API
- इगोर सायसोव द्वारा sysoev.ru/prog/v8.html लेख

एंड्री स्युमिन, प्रमुख, ग्राहक भाग Mail.ru

सर्वर पर जावास्क्रिप्ट, प्रति परिवर्तन 1ms