مقايضات الصورة الأصلية

الصورة الأصلية قوية، لكنها ليست بلا كلفة. فهي تستبدل قابلية JVM للتكيف أثناء التشغيل بسرعة بدء أعلى واستهلاك ذاكرة أقل. ويساعدك فهم هذه المقايضات على تحديد الحالات التي يكون فيها التحول إلى التشغيل الأصلي هو الخيار المناسب.

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

عدم وجود مترجم JIT أو هياكل لتحليل الأداء، إلى جانب وجود heap للصورة محسوب مسبقًا، يعني أن عملية native تستخدم قدرًا أقل بكثير من RAM. يتيح لك ذلك وضع عدد أكبر من المثيلات في كل حاوية وتقليص النطاق بقوة.

هذه هي المقايضة الأهم. يحسّن JIT الأداء باستخدام ملفات تعريف حية لوقت التشغيل، ولذلك يمكن لـ JVM تعمل لفترة طويلة أن تحقق معدل معالجة أقصى أعلى من ملف ثنائي AOT حُسّن دون معرفة مسبقة أثناء البناء. وقد تظل JVM الأفضل في أحمال العمل المستمرة والنشطة باستمرار.

تقلّص GraalVM فجوة معدل المعالجة باستخدام PGO: أنشئ صورة مزودة بأدوات القياس، وشغّل عليها عبء عمل مماثلًا للواقع لجمع ملفات تعريف الأداء، ثم أعد البناء باستخدام تلك الملفات. وهكذا يشبه ملف AOT الثنائي مترجم JIT بعد إحمائه ليتعامل مع عبء العمل نفسه.

إنشاء صورة native بطيء ويستهلك قدرًا كبيرًا من الذاكرة — إذ قد يستغرق دقائق من وقت CPU ويستهلك غيغابايت من RAM في التطبيقات الكبيرة. ويؤدي ذلك إلى إطالة مسارات CI مقارنةً بإنشاء jar سريع.

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

تختلف بعض أدوات JVM عند العمل في الوضع native. فلا تعمل عوامل JVMTI القياسية وبعض أدوات تحليل الأداء على الارتباط بالطريقة نفسها؛ بل تستخدم بدلًا منها أدوات مراقبة أو أخذ عينات مخصصة لـ native-image. لذلك ينبغي التخطيط لاستراتيجية الرصد وفقًا لذلك.

تأتي native image بآليات GC الخاصة بها، وهي GC تسلسلي بسيط وG1 في بعض الإصدارات. أما في ذاكرات heap الكبيرة جدًا، فقد توفر مجموعة GC الكاملة في JVM زمن استجابة أفضل. اختر GC بما يتناسب مع حجم heap في عبء عملك ومتطلبات فترات التوقف.

• وظائف serverless التي تتوسع حتى الصفر.
• أدوات CLI التي يكون فيها بدء التشغيل هو العامل الحاسم.
• الخدمات المصغرة داخل حاويات مضغوطة بكثافة.
• مهام المعالجة الدفعية قصيرة العمر.

• الخدمات طويلة التشغيل والحساسة لمعدل المعالجة، حيث يكون الأداء الأقصى لـ JIT مهمًا.
• التطبيقات التي تعتمد بكثافة على تحميل الأصناف الديناميكي أو إنشاء bytecode.
• أحمال العمل التي تعتمد على أدوات مبنية على JVMTI.

اختبر مدى فهمك للمقايضات المتعلقة بـ native image.

وازنت بين مقايضات native image:

• المزايا: بدء التشغيل خلال أجزاء من الثانية واستهلاك منخفض للذاكرة.
• التكاليف: معدل معالجة أقصى قد يكون أقل، وعمليات بناء بطيئة، وبيانات وصفية للميزات الديناميكية، واختلافات في الأدوات.
• تقلّص PGO فجوة معدل المعالجة من خلال إعادة البناء الموجَّه بملفات تعريف الأداء.
• تناسب native image أدوات CLI وserverless والخدمات المصغرة المضغوطة بكثافة.
• تناسب JVM التطبيقات طويلة التشغيل والحساسة لمعدل المعالجة، والتي تعتمد بكثافة على الميزات الديناميكية.