विकिपीडिया पर जावास्क्रिप्ट लोडिंग का अनुकूलन

सामग्री के लेखक, जिसका अनुवाद आज हम प्रकाशित करते हैं, का कहना है कि उसने सितंबर 2019 के मध्य में, उस परियोजना को पूरा कर लिया है, जिसे वह एक साल से काम कर रहा है। इस परियोजना का लक्ष्य विकिपीडिया की अतुल्यकालिक जावास्क्रिप्ट पाइपलाइन को शुरू करने के लिए आवश्यक आकार के आकार को कम करना था। अर्थात्, प्रकट आकार 36 Kb था। इसे 28 केबीएच से कम में फिट होना था, जो इंटरनेट पैकेट के अनुक्रम के दो 14-किलोबाइट टुकड़े से मेल खाती है।

इस परियोजना का परिणाम दैनिक 4.3 टेराबाइट्स ट्रैफ़िक की बचत थी।


पहले, मेनिफ़ेस्ट आकार 36 Kb से अधिक हो गया, और अनुकूलन के बाद, इसका आकार 28 Kb से छोटा हो गया

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

अनुकूलन प्रक्रिया

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

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

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

मॉड्यूल की संख्या कम करें

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

इस अनुकूलन दृष्टिकोण को लागू करने के बारे में कुछ दिलचस्प बिंदु इस प्रकार हैं:

• WikiEditor एक्सटेंशन में अब पहले की तुलना में 11 कम मॉड्यूल हैं। अन्य 31 मॉड्यूल UploadWizard से हटा दिए गए थे।
• ContentTranslation प्रोग्राम का अनुकूलन करते समय, 24 मॉड्यूल संयुक्त किए गए थे।
• MobileFrontend परियोजना 25 मॉड्यूल जोड़ती है।
• 20 मॉड्यूल RevisionSlider और TwoColConflict से निकाले गए।

यह भी बहुत महत्वपूर्ण है कि विकिपीडिया के लिए विकिपीडिया ग्राहक को अनुकूलित किया गया है। काम का यह हिस्सा खुद एक महाकाव्य परियोजना ( T203696 ) था। प्रारंभ में, 248 व्यक्तिगत मॉड्यूल इस सुविधा को लागू करने के लिए जिम्मेदार थे। हम 200 से अधिक मॉड्यूल से छुटकारा पाने में कामयाब होने के बाद, उनमें से केवल 42 थे।

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

मेटाडेटा आकार कम करें

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

पहला सुधार यह है कि, पहले, EventLogging एक्सटेंशन स्कीमा मेटाडेटा मुख्य मेनिफ़ेस्ट का हिस्सा था। इस तंत्र को फिर से तैयार किया गया था, जिससे कि स्कीमा मेटाडेटा को अब EventLogging ग्राहक JS बंडल में शामिल किया गया। नतीजतन, EventLogging द्वारा पहले किए गए प्रकट आकार में योगदान 90% से अधिक कम हो गया है। इसका मतलब था कि महत्वपूर्ण पथ में अब 2 KB कम डेटा है! इसके अलावा, इसका मतलब है कि EventLogging की क्षमताओं का विस्तार करने से अब प्रकट आकार में वृद्धि नहीं हुई है। ऐसे बंडलों को इकट्ठा करते समय, रिसोर्सलॉडर , पैकेज फाइल्स की एक नई सुविधा का उपयोग किया गया । यह सुविधा फरवरी 2019 में पेश की गई थी, इसमें रुचि के कारणों में से एक यह तथ्य है कि यह रजिस्ट्री में मॉड्यूल की संख्या को कम करने में मदद कर सकता है। पैकेज फ़ाइलें एक ही मॉड्यूल में उत्पन्न डेटा और जावास्क्रिप्ट कोड के संयोजन की प्रक्रिया को बहुत सरल बनाती हैं।

दूसरा सुधार तब हुआ जब हमने प्रत्येक रजिस्ट्री प्रविष्टि ( T229245 ) का औसत आकार घटाया । प्रत्येक मॉड्यूल के लिए मेनिफ़ेस्ट में दो प्रविष्टियाँ होती हैं। यह मॉड्यूल और उसके संस्करण के पहचानकर्ता (आईडी) का नाम है। संस्करण पहचानकर्ता को पहले 7 बाइट्स डेटा की आवश्यकता थी। रिसोर्सलॉडर के संदर्भ में जन्मदिन के विरोधाभास के बारे में सोचने के बाद, हमने फैसला किया कि संस्करण आईडी के लिए संभाव्यता स्पेक्ट्रम को 78 बिलियन से घटाकर "केवल" 60 मिलियन किया जा सकता है। इस पर विवरण कोड टिप्पणियों में पाया जा सकता है। लेकिन, इस सुधार को संक्षेप में, हम कह सकते हैं कि इसने हमें 1,100 मॉड्यूल में से प्रत्येक के विवरण में 2 बाइट्स बचाने की अनुमति दी जो अभी भी रजिस्ट्री में हैं। नतीजतन, प्रकट का आकार एक और 2-3 Kb से कम हो गया था।

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


एक परियोजना के अंतिम चरण में प्रकट होने वाला मैनिफेस्ट

परिवर्तन रिसोर्सलॉडर निगरानी प्रणाली द्वारा कब्जा कर लिया गया था। स्क्रीनशॉट, Grafana के सार्वजनिक उदाहरण में स्थित स्टार्टअप मेनिफ़ेस्ट आकार पैनल दिखाता है। यहां आप देख सकते हैं कि असम्पीडित डेटा स्ट्रीम का आकार 2.8 Kb तक घट गया।

सिस्टम की तैनाती, जो सितंबर के मध्य में हुई, मूल लक्ष्य की उपलब्धि के लिए नेतृत्व किया, जो कि प्रकट को 28 Kb से अधिक नहीं के आकार को संपीड़ित करना था। इस बड़े पैमाने पर परियोजना के कार्यान्वयन ने इस तथ्य को जन्म दिया कि आरंभीकरण प्रकट 9 Kb से कम हो गया था (हम संकुचित डेटा के बारे में बात कर रहे हैं)। एक साल पहले, यह आकार 36.2 Kb था, और परियोजना के पूरा होने के बाद यह पहले से ही 27.2 Kb था।

विकिपीडिया और संबंधित परियोजनाओं पर हर मिनट लगभग 363,000 पृष्ठ दृश्य उत्पन्न होते हैं। एक घंटे में - 21 मिलियन और 800 हजार। दैनिक - 523 मिलियन ( यहां पृष्ठ विचारों पर आंकड़े हैं)। सिस्टम के उस संस्करण को, जिसे सितंबर के मध्य में तैनात किया गया था, जिससे प्रति दिन लगभग 1.4 टेराबाइट्स की बचत हुई। और अगर आप तुलना करते हैं कि एक साल पहले क्या हुआ था, तो आज यह पता चला है कि 4.3 टेराबाइट्स ट्रैफिक अब रोजाना बचते हैं।

आगे क्या है?

हम 28 Kb विकिपीडिया आरंभीकरण प्रकट फिट करने में कामयाब रहे। यह आकार है जो इस तथ्य के कारण चुना गया था कि यह सबसे छोटा आकार है जो कि 14 Kb का एक बहु है। इस आकार के डेटा को ब्राउज़र में प्रसारित इंटरनेट पैकेट के अनुक्रम के टुकड़ों में रखा जा सकता है।

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

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

प्रिय पाठकों! क्या आपने कभी बड़ी इंटरनेट परियोजनाओं के अनुकूलन में भाग लिया है?