من وقت لآخر ، يشكك المطورون الذين يدعمون تطبيقات العقدة القديمة في الحاجة إلى نقل التطبيق من الإصدارات القديمة إلى العقد الجديدة. الحجة الرئيسية لصالح البقاء على القديم هي "أنا لا أستخدم ميزات جديدة ، ولكن تنفيذها سيبطئ بالتأكيد المعالجة ككل". بالإضافة إلى ذلك ، يمكن أن يكون الوضع معقدًا إلى حد كبير من خلال وجود تبعيات على المكتبات التي لم تعد مدعومة تحت العقد الجديدة ، ويتحول التغيير في إصدار العقدة تلقائيًا إلى معالجة مهمة لهندسة التطبيق. مقالتي ، آمل أن تساعدهم على اتخاذ قرار بشأن هذه المسألة.
قبل أن أبدأ ، أذكرك بالمبدأ الأساسي لأعمال تكنولوجيا المعلومات: العمل
، لا تلمس!إذا كان تطبيقك يعمل كما ينبغي ، إذا كان يتواءم تمامًا مع المهام ولا توجد حاجة ملحة لمعالجته ، فمن الأفضل ترك كل شيء كما هو. يمكن أن تكون إعادة التدوير عملية مؤلمة للغاية وطويلة. ونتيجة لذلك ، لن تحصل على أي فوائد ملموسة ، بخلاف الشعور بالرضا الجمالي ، وفي هذا الوقت سيعاني عملك.
مقالتي هي لأولئك الذين لا يزالون بحاجة. سأصف وضعي الأخير ، وأتحدث عن الصعوبات التي واجهتها في حلها ، وسأقدم النتائج التي تلقيتها في النهاية.
أقوم بتطوير نظام لجمع ومعالجة سجلات التطبيقات الأخرى. أعباء العمل الثابتة - مئات الآلاف من السجلات لكل دقيقة لكل مكون. تم تطوير النظام بشكل أفقي بشكل جيد ، ولديه بنية نموذجية ، وعمل بنجاح لأكثر من عام واحد وتعامل مع وظائفه ككل. النسخة المستخدمة من العقدة هي 0.10
ماذا تواجه؟بطبيعة الحال ، لا يوجد نقص في الوظائف. لم يتم اعتبار ميزات es6 الجديدة حجة. بالطبع ، إنهم يجعلون الحياة أجمل ، لكن لا شيء أكثر. بالنسبة لأي من مهامنا ، كانت وظيفة العقدة القديمة كافية تمامًا. ظهرت المشاكل في أكثر الأماكن غير المتوقعة حيث أصبحت الوظيفة أكثر تعقيدًا.
المشكلة الأولى:
فجأة ، بدأ أحد المكونات ذات ذروة الأحمال الواردة واستهلاك الذاكرة أقل من 5 غيغابايت يتباطأ فجأة. لم تحدث المشكلة في كل مرة ، بشكل تلقائي ، عادة قرب نهاية الذروة. إذا لم يسقط التطبيق في المهلات ، يتعافى الأداء تدريجياً في غضون نصف ساعة أو ساعة. شفيت إعادة التشغيل على الفور.
بعد عملية "التصحيح العميق" ، اتضح أن العملية بأكملها تبدأ في التباطؤ ، حتى العمليات المتزامنة ، وهذا هو السبب في أنه تم التوصل إلى أن جامع القمامة نفسه كان "يزداد سوءًا". ما يجب القيام به حيال ذلك لم يكن واضحا تماما. كان الحل الوحيد هو البحث في تاريخ التغييرات في الكود الخاص بنا لعدة أشهر واستعادة الوظائف المهمة. من ناحية أخرى ، لم تحدث المشكلة في كثير من الأحيان ، وليس كل يوم ، وبدا أيضًا أن إعادة التشغيل اليدوي للنظام حل مقبول تمامًا (يعني دليل البرنامج النصي على أساس إشارة كاشف تراكم). كنا أكثر ميلا إلى الخيار الثاني. وإذا لم يكن للمشكلة الثانية ، فمن المرجح أنه تم تنفيذها.
المشكلة الثانية:
عنصر آخر من مكوناتنا كان تناول الكثير من الذاكرة. نظرًا لأن هذا المكون كان في الواقع ذاكرة تخزين مؤقت ، فإن "جشعه" كان مفسرًا من حيث المبدأ. حتى اللحظة التي كان مطلوبًا فيها تحديدها من الأعلى إلى حجم محدد بدقة. ثم اتضح أن المكون يكتسب ذاكرة وأنه ليس في عجلة من أمره للتخلي عنه. وحتى العمل بسرعة خاملة تقريبًا. أي أنه في وقت ذروة الحمل ، اختار مدير ذاكرة العقدة الحد الأقصى للذاكرة ، وحتى مع الهامش ، ثم احتفظ بها حتى نهاية القرن (إعادة تشغيل المكون ، على سبيل المثال). سأذكر على الفور أنه تم بطبيعة الحال فحص خيار التسرب والتحقق منه. للأسف ، لم تكن هناك تسريبات ، ومرة أخرى كنا في طريق مسدود.
حاولت أن أسأل في أماكن مختلفة على الإنترنت عن كيفية إدارة الذاكرة للعقدة وكيفية حل موقفنا. ولكن رداً على ذلك ، تلقيت الكثير من السلبية فيما يتعلق باستخدام العقدة 0.10. بشكل عام ، كانت هذه السلبية هي التي نقلتني إلى مهمة التحول إلى أحدث إصدارات العقدة.
ما الذي كان يتراجع؟1. الخوف من فقدان الإنتاجية.
يتذكر أولئك الذين عملوا على الثعبان أن الانتقال من خط 2.x إلى 3.x كان مصحوبًا بفقدان كبير في الإنتاجية. أنا لا أعرف كيف تسير الأمور في الثعبان الآن ، ربما تحسن الوضع. ولكن من المنطقي أن نتوقع أنه بعد إضافة كل هذه الميزات الجديدة إلى es6 ، يمكن أن تغرق العقدة بقوة. حاولت جوجل بعض المعايير لمقارنة العقد الجديدة مع العقد القديمة ، لم أجد أي شيء معقول.
2. أداء JSON.parse
نظرًا لأننا نعمل مع السجلات ، فإن JSON.parse تحتل نصيب الأسد من المعالج. في وقت واحد ، قمنا بمقارنتها مع إصدارات مختلفة من العقدة وحصلنا على انخفاض في الأداء بنحو 30 ٪. تمت مقارنة العقدة 4.x مع 0.10 و 0.12.
في الواقع ، لم تكن هذه الأسباب حاسمة ، لأن المعالج لم يكن اختناق. بالإضافة إلى ذلك ، لمثل هذه المهام هناك تحجيم أفقي.
3. تبعيات العبوة
لكن هذا كان حجر عثرة. استخدم المكون الأكثر تعقيدًا لدينا حزمة libmysqlclient ، والتي تعمل فقط تحت العقدة 0.10. الأسوأ ، مكالماته المتزامنة. أي أنه كان من المستحيل ببساطة تغيير برنامج تشغيل الخلية ، واستبدال مكالمة بأخرى ، دون معالجة معمقة للمكونات من المعالجة المتزامنة جزئيًا إلى المعالجة غير المتزامنة تمامًا. علاوة على ذلك ، لم يكن الجزء الأكثر صعوبة في هذه المهمة هو المعالجة نفسها بقدر ما هو كيفية تبرير الإدارة لحاجتها وإظهار ما سيعطي المشروع بالضبط :)
ما أعطى؟ونتيجة لذلك ، ما زلنا ننتقل من العقدة 0.10 إلى آخر lts 8.11.x
1. لا يوجد انخفاض في الأداء. على العكس ، تلقينا زيادة في الطلب بنسبة 10-15٪
2. تحسن كبير في استهلاك الذاكرة ، حوالي 30-50٪ ، حسب المكون
3. تم حل المشاكل "غير القابلة للحل" التي تم التعبير عنها أعلاه بنفسها
4. حصلنا أخيرًا على فرصة لاستخدام ميزات جديدة من es6! على الرغم من أنها خارج العادة ، ما زلنا لا نستخدمها بعد)))