تحسين تحميل جافا سكريبت على ويكيبيديا

يقول مؤلف المادة ، التي نُنشر ترجمتها اليوم ، إنه في منتصف سبتمبر 2019 ، أنهى أخيرًا المشروع الذي كان يعمل عليه لمدة عام. كان الهدف من هذا المشروع هو تقليل حجم البيان المطلوب لتهيئة خط أنابيب جافا سكريبت غير المتزامن ليكيبيديا. وهي أن حجم البيان كان 36 كيلو بايت. كان يجب أن يصل حجمه إلى أقل من 28 كيلوبايت ، وهو ما يتوافق مع شريحتين بحجم 14 كيلوبايت من تسلسل حزم الإنترنت.

وكانت نتيجة هذا المشروع توفير يومي قدره 4.3 تيرابايت من حركة المرور.


في البداية ، تجاوز حجم البيان 36 كيلو بايت ، وبعد التحسين ، أصبح حجمه أصغر من 28 كيلو بايت

يوضح الرسم البياني انخفاضًا تدريجيًا في حجم البيان. نحن نتحدث عن البيانات المضغوطة (أي أنها تمثل الحمل الصافي على الشبكة ، مما يؤدي إلى نقل هذه البيانات من الخادم إلى المستعرض).

عملية التحسين

يتم تمثيل بيان التهيئة ببيانات ليست سهلة التحسين. الجزء الأكبر من الكود ليس شيئًا مثل المنطق الوظيفي الذي يمكن تحسينه بالوسائل التقليدية. بدلاً من ذلك ، يتم تمثيل البيان بالكامل تقريبًا بالبيانات الخالصة. يتم إنشاء هذه البيانات تلقائيًا بواسطة نظام تسليم محتوى ResourceLoader . هم سجل من حزم الوحدة النمطية. تستخدم ويكيبيديا نظام ResourceLoader للعمل مع موارد JavaScript و CSS والنص.

يشتمل السجل على بيانات وصفية لجميع وظائف الواجهة الأمامية المنشورة على ويكيبيديا. يسرد البيان أسماء الحزم ، إصداراتها الحالية ، تبعياتها على حزم أخرى مماثلة موصوفة هنا.

لقد بدأت بالبحث عن رمز لم يتم استخدامه مطلقًا في الممارسة ( T202154 ). وشمل ذلك العثور على أجزاء غير كاملة أو منسية من التعليمات البرمجية المتعلقة بالميزات القديمة. تمت إزالة الشفرة غير المستخدمة على الفور لضمان التوافق مع المتصفحات التي لم تعد تجتاز اختبارنا ، مما يضمن إدراجها في مجموعة المتصفحات الحديثة ( الصف أ ). أعددت أيضًا مستندًا عن أداء تحميل الصفحة. تم استخدام هذا المستند كمرجع ، مما يسمح للمطورين بفهم تأثير التغييرات التي تحدث على أنواع مختلفة على المراحل المختلفة لعملية تحميل الصفحة.

تقليل عدد الوحدات

كانت الخطوة التالية هي التعاون مع الفرق الهندسية لمؤسسة Wikimedia و Wikimedia Deutschland. نحتاج إلى معرفة ميزات النظام التي تستخدم عددًا كبيرًا من الوحدات. على سبيل المثال ، بعد فهم هذا الأمر ، سيكون من الممكن الجمع بين حزم مبعثرة مسبقًا تم بناء وظيفة معينة منها. هذه الحزم ، حتى في حالة متناثرة ، يتم تحميلها معًا دائمًا. سيؤدي ذلك إلى حقيقة أنه سيكون هناك عدد أقل من نقاط النهاية في النظام الذي يجب تخزين بيانات التعريف الخاصة به في السجل الذي تم تكوينه بواسطة ResourceLoader.

فيما يلي بعض النقاط المثيرة للاهتمام حول تطبيق نهج التحسين هذا:

• يحتوي ملحق WikiEditor الآن على 11 وحدة أقل من ذي قبل. تمت إزالة 31 وحدة أخرى من UploadWizard.
• عند تحسين برنامج ContentTranslation ، تم دمج 24 وحدة.
• يجمع مشروع MobileFrontend بين 25 وحدة.
• تمت إزالة 20 وحدة من RevisionSlider و TwoColConflict.

من المهم أيضًا تحسين عميل Wikidata لـ Wikipedia. كان هذا الجزء من العمل نفسه عبارة عن مشروع ملحمي ( T203696 ). في البداية ، كانت 248 وحدة فردية مسؤولة عن تنفيذ هذه الميزة. بعد أن تمكنا من التخلص من أكثر من 200 وحدة ، كان هناك 42 منها فقط.

يوضح الرسم البياني أعلاه التحسينات الصغيرة التي تمت للمشروع على مدار العام. كلهم اقتربونا من الهدف. أود بصفة خاصة أن أشير إلى قطرتين كبيرتين في حجم البيان. حدث مثل هذا السقوط في الأسبوع الأول من شهر أغسطس. ثم تم نشر نسخة محسنة من Wikidata. يمكن ملاحظة الانخفاض الثاني في الحجم في نهاية الرسم البياني. لقد حدث ذلك في منتصف سبتمبر. الآن أود أن أخبرك عنه.

تقليل أحجام البيانات الوصفية

أصبح التحسن في البيان الذي حدث في منتصف سبتمبر ممكناً بفضل تغييرين عالميين كانا يهدفان إلى تنظيم بيانات أكثر ذكاءً.

التحسين الأول هو أنه في وقت سابق ، كانت بيانات تعريف مخطط تمديد EventLogging جزءًا من البيان الرئيسي. تم إعادة هيكلة هذه الآلية ، مما جعل البيانات الوصفية للمخطط مدرجة الآن في حزمة JS الخاصة بعميل EventLogging. نتيجة لذلك ، تم تقليل المساهمة في حجم البيان الذي تم تقديمه مسبقًا بواسطة EventLogging بأكثر من 90٪. هذا يعني أن المسار الحرج يحتوي الآن على بيانات أقل بمقدار ٢ كيلوبايت! هذا ، بالإضافة إلى ذلك ، يعني أن توسيع قدرات EventLogging لم يعد يؤدي إلى زيادة في حجم البيان. عند تجميع هذه الحزم ، تم استخدام ميزة جديدة لـ ResourceLoader ، ملفات الحزمة . تم تقديم هذه الميزة في فبراير 2019 ، أحد أسباب الاهتمام بها هو أنها يمكن أن تساعد في تقليل عدد الوحدات في السجل. تعمل حزمة الملفات على تبسيط عملية دمج البيانات التي تم إنشاؤها ورمز JavaScript في وحدة نمطية واحدة.

حدث التحسن الثاني عندما خفضنا متوسط ​​حجم كل إدخال تسجيل ( T229245 ). يحتوي البيان على عنصرين لكل وحدة. هذا هو اسم الوحدة النمطية والمعرف (ID) لإصدارها. معرف الإصدار المطلوب مسبقًا 7 بايت من البيانات. بعد التفكير في مفارقة أعياد الميلاد في سياق ResourceLoader ، قررنا أن طيف الاحتمالات لمعرفات الإصدار يمكن تخفيضه بأمان من 78 مليار إلى 60 مليون "فقط". يمكن الاطلاع على التفاصيل الخاصة بهذا في تعليقات الكود. ولكن لتلخيص هذا التحسن ، يمكننا القول أن هذا سمح لنا بحفظ وحدتي بايت في وصف كل وحدة من الوحدات التي لا تزال موجودة في السجل والتي يبلغ عددها 1100 وحدة. نتيجة لذلك ، تم تقليل حجم البيان بواقع 2-3 كيلوبايت.

يوجد أدناه جزء كبير من المخطط يوضح الأيام الأخيرة من التشغيل (هذه المؤشرات مأخوذة من نظام المراقبة الاصطناعية ، وتستخدم البيانات غير المضغوطة هنا).


تغيير حجم البيان في المرحلة الأخيرة من المشروع

تم التقاط التغيير بواسطة نظام مراقبة ResourceLoader. تعرض لقطة شاشة لوحة حجم بدء التشغيل الموجودة في مثيل عام في Grafana. هنا يمكنك أن ترى أن حجم دفق البيانات غير المضغوطة انخفض بمقدار 2.8 كيلو بايت.

أدى نشر النظام ، الذي حدث في منتصف سبتمبر ، إلى تحقيق الهدف الأصلي ، وهو ضغط البيان إلى حجم لا يتجاوز 28 كيلو بايت. أدى تنفيذ هذا المشروع الكبير إلى تخفيض بيان التهيئة بمقدار 9 كيلوبايت (نحن نتحدث عن البيانات المضغوطة). قبل عام ، كان هذا الحجم 36.2 كيلو بايت ، وبعد الانتهاء من المشروع كان بالفعل 27.2 كيلو بايت.

يتم إنشاء حوالي 363000 صفحة مشاهدة كل دقيقة على ويكيبيديا والمشاريع ذات الصلة. في ساعة - 21 مليون و 800 ألف. يوميًا - 523 مليون (فيما يلي إحصائيات حول مشاهدات الصفحة). أدى هذا الإصدار من النظام ، الذي تم نشره في منتصف سبتمبر ، إلى توفير ما يقرب من 1.4 تيرابايت من حركة المرور في اليوم الواحد. وإذا قارنت ما هو اليوم مع ما كان عليه قبل عام ، اتضح أنه يتم الآن حفظ 4.3 تيرابايت من حركة المرور يوميًا.

ما التالي؟

لقد نجحنا في احتواء بيان تهيئة ويكيبيديا البالغ 28 كيلوبايت. هذا هو الحجم الذي تم اختياره نظرًا لحقيقة أنه أصغر حجم هو مضاعف 14 كيلو بايت. يمكن وضع البيانات بهذا الحجم في أجزاء من تسلسل حزم الإنترنت المرسلة إلى المستعرض.

الآن نواجه مهمة جديدة: عدم التخلي عن المناصب. في العام الماضي ، كنت أراقب عن كثب البيان . لقد فعلت ذلك من أجل التأكد من نجاحاتنا واكتشاف المشكلات المحتملة التي تعيقنا. في النهاية ، قمت بأتمتة هذه العملية باستخدام لوحة Grafana العامة.

إذا كنت تعتقد أن هذه اللوحة ، فلا يزال لدينا العديد من الفرص لتحسين تغليف الكود ، ولحل المشكلات التي تعد أقوى من الآن ، يمكنك تسهيل إنشاء حزم. آمل أن تكون هذه التحسينات القادمة مفيدة لنا ، لكننا نعمل حاليًا على تطوير إمكانات جديدة للنظام ، بينما نسعى جاهدين للامتثال لمتطلبات مستوى أداء المشروع.

أعزائي القراء! هل سبق لك أن شاركت في تحسين مشاريع الإنترنت الكبيرة؟