مقدمة

في الجزء الثامن، قدمنا ​​المفهوم الكامن وراء وظيفة Spring Cloud وفي الجزء التاسع أوضحنا كيفية تطوير AWS Lambda باستخدام Spring Cloud Function باستخدام Java 21 وSpring Boot 3.2. في هذه المقالة من السلسلة، سنقيس وقت البدء البارد والدافئ بما في ذلك تمكين SnapStart على وظيفة Lambda ولكن أيضًا تطبيق تقنيات تمهيدية متنوعة مثل تحضير استدعاء DynamoDB وإعداد (تفويض) طلب بوابة API بالكامل دون المرور عبر الشبكة . سنستخدم نموذج تطبيق Spring Boot 3.2 لقياساتنا، ولجميع وظائف Lambda، استخدم JAVA_TOOL_OPTIONS: "-XX: TieredCompilation -XX:TieredStopAtLevel=1" ومنحهم ذاكرة Lambda سعة 1024 ميجابايت.

قياس فترات البدء الباردة والوقت الدافئ باستخدام وظيفة Spring Cloud واستخدام Java 21 وSpring Boot 3.2

لنبدأ بشرح كيفية تمكين AWS SnapStart على وظيفة Lambda لأنها (مع التمهيد في الأعلى) توفر أكبر إمكانات تحسين أداء Lambda (خاصة أوقات البدء الباردة). إنها مجرد مسألة تكوين:

SnapStart:
  ApplyOn: PublishedVersions 

يتم تطبيقه في خصائص وظيفة Lambda أو قسم الوظيفة العامة في قالب SAM. أود أن أتعمق أكثر في كيفية استخدام تقنيات التحضير المختلفة أعلى SnpaStart في حالة الاستخدام الخاصة بنا. لقد شرحت الأفكار الكامنة وراء الإعداد الأولي في مقالتي AWS Lambda SnapStart - قياس الإعداد الأولي ووقت الاستجابة الشامل ووقت النشر

1) يمكن العثور على رمز إعداد طلب DynamoDB هنا.

تقوم هذه الفئة أيضًا بتنفيذ واجهة استيراد org.crac.Resource لمشروع CraC.

مع هذا الدعاء

Core.getGlobalContext().register(this);

تسجل فئة GetProductByIdWithDynamoDBRequestPrimingHandler نفسها كمورد CRaC.

نقوم أيضًا بإعداد استدعاء DynamoDB من خلال تنفيذ طريقة beforeCheckpoint من CRaC API.

      @Override
      public void beforeCheckpoint(org.crac.Context extends Resource> context) throws Exception {
             productDao.getProduct("0");
      }

والذي سنستدعيه أثناء مرحلة نشر Lambda funtiom وقبل التقاط لقطة Firecracker microVM.

2) يمكن العثور على الكود الخاص بطلب بوابة API بالكامل هنا.

تقوم هذه الفئة أيضًا بتنفيذ واجهة الاستيراد org.crac.Resource كما في المثال أعلاه.
سنعيد استخدام التقنية القبيحة التي وصفتها في مقالتي AWS Lambda SnapStart - الجزء 6 تمهيد استدعاء الطلب لإطارات عمل Java 11 وMicronaut وQuarkus وSpring Boot. لا أوصي باستخدام هذه التقنية في الإنتاج، ولكنها توضح الإمكانات الإضافية لتقليل البداية الباردة باستخدام إعداد طلب بوابة API بالكامل عن طريق التحميل المسبق للتعيين بين نماذج Spring Boot وSpring Cloud Function ونموذج Lambda الذي يؤدي أيضًا DynamoDB تمهيد الاستدعاء.

يبدو إنشاء طلب بوابة API لـ /products/{id} بمعرف يساوي 0 طلب API Gateway JSON كما يلي:

      private static String getAPIGatewayRequestMultiLine () {
             return  """
                        {
                      "resource": "/products/{id}",
                      "path":  "/products/0",
                      "httpMethod": "GET",
                      "pathParameters": {
                            "id": "0" 
                        },
                       "requestContext": {
                          "identity": {
                        "apiKey": "blabla"
                      }
                      }
                    }
           """;
      }

beforeCheckpoint عند إعداد أولية (وكلاء) لطلب بوابة API بالكامل دون المرور عبر الشبكة باستخدام فئة Spring Cloud Function FunctionInvocer التي تستدعي طريقة HandleRequest الخاصة بها عن طريق تمرير دفق الإدخال لواجهة برمجة التطبيقات (API) تم إنشاء طلب Gateway JSON أعلاه على النحو التالي:

@Override
public void beforeCheckpoint(org.crac.Context extends Resource> context) throws Exception {
            
new FunctionInvoker().handleRequest( 
  new ByteArrayInputStream(getAPIGatewayRequestMultiLine().
  getBytes(StandardCharsets.UTF_8)),
  new ByteArrayOutputStream(), new MockLambdaContext());
}

اعتمدت نتائج التجربة أدناه على إعادة إنتاج أكثر من 100 درجة حرارة باردة وحوالي 100.000 نقطة دافئة مع وظيفة Lambda مع إعداد ذاكرة سعة 1024 ميجابايت لمدة ساعة واحدة. لقد استخدمت أداة اختبار التحميل، ولكن يمكنك استخدام أي أداة تريدها، مثل المدفعية بدون خادم أو ساعي البريد.

لقد أجريت كل هذه التجارب بأربعة سيناريوهات مختلفة:

1) لم يتم تمكين SnapStart

في template.yaml استخدم التكوين التالي:

    Handler: org.springframework.cloud.function.adapter.aws.FunctionInvoker::handleRequest    
      #SnapStart:
         #ApplyOn: PublishedVersions      

ونحتاج إلى استدعاء وظيفة Lambda بالاسم GetProductByIdWithSpringBoot32SCF الذي تم تعيينه لفئة GetProductByIdHandler Lambda Handler Java.

2) تم تمكين SnapStart ولكن لم يتم تطبيق أي إعداد أولي

في template.yaml استخدم التكوين التالي:

    Handler: org.springframework.cloud.function.adapter.aws.FunctionInvoker::handleRequest 
    SnapStart:
      ApplyOn: PublishedVersions 

ونحتاج إلى استدعاء نفس وظيفة Lambda بالاسم GetProductByIdWithSpringBoot32SCF الذي تم تعيينه لفئة GetProductByIdHandler Lambda Handler Java.
3) تم تمكين SnapStart مع إعداد استدعاء DynamoDB

في template.yaml استخدم التكوين التالي:

    Handler: org.springframework.cloud.function.adapter.aws.FunctionInvoker::handleRequest    
    SnapStart:
      ApplyOn: PublishedVersions      

ونحتاج إلى استدعاء وظيفة Lambda بالاسم GetProductByIdWithSpringBoot32SCFAndDynamoDBRequestPriming الذي تم تعيينه لفئة GetProductByIdWithDynamoDBRequestPrimingHandler Lambda Handler Java.

4) تم تمكين SnapStart مع إعداد/تفويض استدعاء طلب بوابة واجهة برمجة التطبيقات

في template.yaml استخدم التكوين التالي:

    Handler: org.springframework.cloud.function.adapter.aws.FunctionInvoker::handleRequest
    SnapStart:
      ApplyOn: PublishedVersions      

ونحن بحاجة إلى استدعاء وظيفة Lambda بالاسم
GetProductByIdWithSpringBoot32SCFAndWebRequestPriming الذي تم تعيينه لفئة Java GetProductByIdWithWebRequestPrimingHandler Lambda Handler.

الاختصار c للبداية الباردة وw للبداية الدافئة.

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

خاتمة

من خلال تمكين SnapStart على وظيفة Lambda وحدها، فإنه يقلل من وقت البدء البارد لوظيفة Lambda بشكل كبير. من خلال استخدام إعداد استدعاء DynamoDB بالإضافة إلى ذلك، سنكون قادرين على تحقيق بدايات باردة أعلى قليلاً فقط من بدايات التشغيل الباردة الموضحة في مقالتي AWS SnapStart - قياس البرودة والدفء يبدأ باستخدام Java 21 باستخدام إعدادات ذاكرة مختلفة حيث قمنا بقياس البدايات الباردة والدافئة لـ Lambda النقي تعمل دون استخدام أي أطر عمل بما في ذلك إعداد ذاكرة بسعة 1024 ميجابايت كما هو الحال في السيناريو الخاص بنا.

بمقارنة أوقات البدء الباردة والساخنة التي قمنا بقياسها باستخدام AWS Serverless Java Container في المقالة قياس فترات البدء الباردة والساخنة باستخدام AWS Serverless Java Container وقياس فترات البدء الباردة والساخنة باستخدام AWS Lambda Web Adaptor، نلاحظ أن وظيفة Spring Cloud توفر برودة أعلى أوقات البدء مقارنةً بـ AWS Lambda Web Adaptor ولكن أوقات البدء الباردة قابلة للمقارنة تمامًا مع AWS Serverless Java Container (تختلف النتائج قليلاً اعتمادًا على النسب المئوية). فيما يتعلق بأوقات البدء/التنفيذ الدافئة، فإن جميع الأساليب الثلاثة لها نتائج قابلة للمقارنة تمامًا عند النظر بشكل خاص إلى النسب المئوية الأقل من 99.9.