مقدمة

حتى الآن لم أقم بقياس الأداء (أوقات البدء الدافئة والباردة) لوظائف Lambda باستخدام وقت تشغيل Java 21 لبعض حالات الاستخدام (مثل تقديم طلب DynamoDB) لبنية Arm64 لأنها لا تدعم SnapStart. سوف يتفوق أداء Lambda مع وقت تشغيل Java 21 مع بنية x86_64 مع تمكين SnapStart (وأكثر من ذلك مع تحسين الإعداد الإضافي) على Lambda مع بنية Arm64. ولكن في 18 يوليو 2024، أعلنت AWS أن AWS Lambda تدعم الآن وظائف SnapStart لـ Java التي تستخدم بنية ARM64. لذا، كان من المنطقي الآن بالنسبة لي أن أبدأ في قياس أوقات البدء الباردة والدافئة مع الأخذ في الاعتبار أيضًا اختيار بنية وظيفة Lambda. من المعروف أنه مع إعداد ذاكرة تسعير AWS Lambda الحالي ومدة التنفيذ، سيكون Lambda مع بنية Arm64 تقريبًا. أرخص بنسبة 25% من Lambda مع بنية x86_64.

قررت إنشاء سلسلة مقالات منفصلة لها وعدم إضافة هذا الموضوع إلى سلسلة AWS Lambda SnapStart المتنامية باستمرار.

يبدأ قياس درجات الحرارة الباردة والدافئة لتطبيق المثال

في تجربتنا، سنعيد استخدام التطبيق المقدم في المقالة AWS Lambda SnapStart - قياس عمليات التشغيل الباردة لـ Java 21 Lambda. هنا هو رمز التطبيق عينة. توجد في الأساس وظيفتان رئيسيتان من وظائف Lambda تستجيب كل منهما لطلبات API Gateway لإنشاء المنتج بالمعرف المحدد (راجع وظيفة PutProductFunction Lambda) واسترداد المنتج بواسطة المعرف المحدد (راجع وظيفة GetProductByIdFunction Lambda). يمكنك استخدام وظيفتي Lambda مع تمكين SnapStart وبدونه. هناك وظيفة Lambda إضافية GetProductByIdWithPrimingFunction والتي كتبتها لقياس تأثير إعداد طلب DynamoDB بشكل مستقل لوظيفة Lambda التي تم تمكين SnapStart. يمكنك قراءة المزيد حول تأثير الإعداد في مقالتي AWS Lambda SnapStart - قياس الإعداد ووقت الاستجابة من البداية إلى النهاية ووقت النشر.

لتمكين SnapStart على جميع وظائف Lambda، يرجى إلغاء التعليق التالي في قالب SAM:

Globals:
  Function:
    CodeUri: target/aws-pure-lambda-snap-start-21-1.0.0-SNAPSHOT.jar
    ...
    SnapStart:
     ApplyOn: PublishedVersions  
   ...

إذا كنت أرغب في استخدام SnapStart فقط للفرد، ولكن ليس لجميع وظائف Lambda، فيجب عليك تطبيق تعريف SnapStart هذا على مستوى وظيفة Lambda بدلاً من مستوى الوظيفة العامة.

تحتوي جميع وظائف Lambda على الإعدادات التالية كنقطة بداية:

• إعداد الذاكرة 1024 ميجابايت
• عميل HTTP Apache الافتراضي المستخدم للتحدث مع قاعدة بيانات DynamoDB
• خيار تجميع Java "-XX: TieredCompilation -XX:TieredStopAtLevel=1" والذي أثبت أنه يوفر مقايضة جيدة جدًا بين أوقات البدء الباردة والدافئة

في قالب SAM أضفت إمكانية تحديد بنية Lambda في قسم وظائف Lambda العالمية مثل:

Globals:
  Function:
    CodeUri: target/aws-pure-lambda-snap-start-21-1.0.0-SNAPSHOT.jar
    ...
    Architectures:
      #- arm64
      - x86_64   

فقط قم بإلغاء التعليق على البنية التي ترغب في استخدامها لوظائف Lambda الخاصة بك.

حتى لو كانت لغة Java هي "الكتابة مرة واحدة، والتشغيل في كل مكان"، فقد قمت على أي حال بتجميع وإنشاء ملف jar التطبيق لقياسات الذراع 64 الخاصة بي على مثيل t4g AWS EC2 مع معالج Graviton (الذي يعتمد على بنية الذراع 64/aarch64) عن طريق التثبيت مسبقًا أمازون كوريتو 21 لنظام التشغيل Linux aarch64. يمكنك العثور على هذه الجرة هنا.

لقد قمت أيضًا بإعادة قياس كل شيء لبنية x86_64 مرة أخرى للحصول على نتائج قابلة للمقارنة باستخدام نفس إصدار وقت التشغيل Corretto Java 21 والذي كان في وقت قياساتي Java 21.v17 .

اعتمدت نتائج التجربة أدناه على إعادة إنتاج أكثر من 100 بداية باردة وحوالي 100.000 بداية دافئة. من أجل ذلك (والتجارب من مقالتي السابقة) استخدمت أداة اختبار التحميل، ولكن يمكنك استخدام أي أداة تريدها، مثل Serverless-artillery أو Postman. من المهم أيضًا أن تدرك أنني بدأت القياسات مباشرة بعد نشر (إعادة) كود المصدر الجديد للتطبيق. يرجى ملاحظة أن هناك أيضًا تأثير لذاكرة التخزين المؤقت المتدرجة على البداية الباردة، حيث تكون الاستدعاءات الأولى أبطأ بشكل عام، وتصبح الاستدعاءات اللاحقة أسرع حتى يتم الوصول إلى عدد معين من الاستدعاءات.

الآن دعونا نضع جميع القياسات لـ "الحصول على المنتج حسب المعرف الموجود" (وظائف Lambda GetProductByIdFunction وGetProductByIdWithPrimingFunction لتمكين SnapStart والقياسات التمهيدية) معًا.

وقت البدء البارد (ج) والدافئ (م) بالمللي ثانية:

خاتمة

في هذه المقالة قمنا بمقارنة قياسات أوقات البدء الباردة والدافئة لوظيفة Lambda المتصلة بقاعدة بيانات DynamoDB لثلاث حالات استخدام:

• بدون تمكين SnapStart في وظيفة Lambda
• مع تمكين SnapStart في وظيفة Lambda ولكن بدون التحسين الأولي
• مع تمكين SnapStart في وظيفة Lambda ومع إعداد طلب DynamoDB

لقد رأينا أنه باستخدام بنية x86_64، كانت جميع أوقات البدء الباردة والدافئة أقل مقارنةً ببنية Arm64. ولكن نظرًا لأن تسعير Lambda لبنية أرخص بنسبة 25% من بنية x86_64، فإنه يقدم مقايضة مثيرة للاهتمام بين أداء التكلفة.

بالنسبة لقياساتنا، لجميع حالات الاستخدام الثلاثة:

• كانت أوقات بدء Lambda الباردة مع بنية Arm64 بالنسبة للعديد من النسب المئوية 10-20% فقط (وفقط في حالات نادرة جدًا 25-27%) أبطأ مقارنة ببنية x86_64.
• كانت أوقات بدء Lambda الدافئة مع بنية Arm64 أبطأ بالنسبة للعديد من النسب المئوية بنسبة 5-10٪ فقط مقارنة ببنية x86_64.

لذا، يعد اختيار بنية Arm64 معقولًا جدًا لهذا التطبيق النموذجي. وبما أن دعم SnapStart لبنية Arm64 قد تم تقديمه مؤخرًا فقط، فإنني أتوقع أيضًا بعض التحسينات في الأداء في المستقبل. يرجى إجراء القياسات الخاصة بك لحالة الاستخدام الخاصة بك!

في الجزء التالي من المقالة سنقوم بنفس قياسات الأداء ولكن مع ضبط ذاكرة Lambda على قيم مختلفة بين 256 و2048 ميجابايت ومقارنة النتائج.