Einführung

In Teil 8 stellen wir das Konzept hinter der Spring Cloud-Funktion vor und in Teil 9 zeigen wir, wie man AWS Lambda mit Spring Cloud Function unter Verwendung von Java 21 und Spring Boot 3.2 entwickelt. In diesem Artikel der Serie messen wir die Kalt- und Warmstartzeit, einschließlich der Aktivierung von SnapStart für die Lambda-Funktion, aber auch der Anwendung verschiedener Vorbereitungstechniken wie der Vorbereitung des DynamoDB-Aufrufs und der Vorbereitung (Proxy) der gesamten API-Gateway-Anfrage, ohne über das Netzwerk zu gehen . Wir verwenden die Beispielanwendung Spring Boot 3.2 für unsere Messungen und verwenden für alle Lambda-Funktionen JAVA_TOOL_OPTIONS: „-XX: TieredCompilation -XX:TieredStopAtLevel=1“ und geben ihnen Lambda 1024 MB Speicher.

Messen von Kaltstarts und Warmzeit mit Spring Cloud Function und Verwendung von Java 21 und Spring Boot 3.2

Beginnen wir mit der Erläuterung, wie man AWS SnapStart für die Lambda-Funktion aktiviert, da diese (mit der Grundierung oben) das größte Optimierungspotenzial für die Lambda-Leistung (insbesondere Kaltstartzeiten) bietet. Es ist nur eine Frage der Konfiguration:

SnapStart:
  ApplyOn: PublishedVersions 

wird in den Lambda-Funktionseigenschaften oder im globalen Funktionsabschnitt der SAM-Vorlage angewendet. Für unseren Anwendungsfall möchte ich näher auf die Verwendung verschiedener Priming-Techniken zusätzlich zu SnpaStart eingehen. Die Ideen hinter dem Priming habe ich in meinem Artikel AWS Lambda SnapStart – Messung von Priming, End-to-End-Latenz und Bereitstellungszeit

1) Den Code zum Priming der DynamoDB-Anfrage finden Sie hier.

Diese Klasse implementiert zusätzlich die Schnittstelle import org.crac.Resource des CraC-Projekts.

Mit diesem Aufruf

Core.getGlobalContext().register(this);

GetProductByIdWithDynamoDBRequestPrimingHandler-Klasse registriert sich selbst als CRaC-Ressource.

Wir bereiten den DynamoDB-Aufruf zusätzlich vor, indem wir die Methode beforeCheckpoint aus der CRaC-API implementieren.

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

die wir während der Bereitstellungsphase der Lambda-Funktion aufrufen werden und bevor der Firecracker-MicroVM-Snapshot erstellt wird.

2) Den Code zum Priming der gesamten API-Gateway-Anfrage finden Sie hier.

Diese Klasse implementiert außerdem zusätzlich die Schnittstelle import org.crac.Resource wie im obigen Beispiel.
Wir werden die hässliche Technik wiederverwenden, die ich in meinem Artikel AWS Lambda SnapStart – Teil 6 Priming the request invocation for Java 11 and Micronaut, Quarkus and Spring Boot Frameworks beschrieben habe. Ich empfehle nicht, diese Technik in der Produktion zu verwenden, aber sie zeigt die weiteren Möglichkeiten zur Reduzierung des Kaltstarts durch Priming der gesamten API-Gateway-Anfrage durch Vorladen der Zuordnung zwischen Spring Boot- und Spring Cloud-Funktionsmodellen und Lambda-Modell, das auch DynamoDB ausführt Aufruf-Priming.

Die API-Gateway-Anfragekonstruktion der /products/{id} mit der ID gleich 0 sieht folgendermaßen aus:

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

Der beforeCheckpoint, wenn die gesamte API-Gateway-Anfrage vorbereitet (Proxys) wird, ohne das Netzwerk zu durchlaufen, mithilfe der Spring Cloud Function-Klasse FunctionInvoker, die ihre handleRequest-Methode aufruft, indem sie den Eingabestrom der API übergibt Die oben beschriebene Gateway-JSON-Anfrage sieht wie folgt aus:

@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());
}

Die Ergebnisse des folgenden Experiments basierten auf der Reproduktion von mehr als 100 Kalt- und etwa 100.000 Warmstarts mit Lambda-Funktion mit 1024 MB Speichereinstellung für die Dauer von 1 Stunde. Dafür habe ich das Lasttest-Tool verwendet, aber Sie können jedes beliebige Tool verwenden, z. B. Serverless-Artillery oder Postman.

Ich habe alle diese Experimente mit 4 verschiedenen Szenarien durchgeführt:

1) Kein SnapStart aktiviert

Verwenden Sie in template.yaml die folgende Konfiguration:

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

und wir müssen die Lambda-Funktion mit dem Namen GetProductByIdWithSpringBoot32SCF aufrufen, die der Java-Klasse GetProductByIdHandler Lambda Handler zugeordnet ist.

2) SnapStart aktiviert, aber keine Grundierung angewendet

Verwenden Sie in template.yaml die folgende Konfiguration:

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

und wir müssen dieselbe Lambda-Funktion mit dem Namen GetProductByIdWithSpringBoot32SCF aufrufen, die der Java-Klasse GetProductByIdHandler Lambda Handler zugeordnet ist.
3) SnapStart aktiviert mit DynamoDB-Aufrufpriming

Verwenden Sie in template.yaml die folgende Konfiguration:

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

und wir müssen die Lambda-Funktion mit dem Namen GetProductByIdWithSpringBoot32SCFAndDynamoDBRequestPriming aufrufen, die der Java-Klasse GetProductByIdWithDynamoDBRequestPrimingHandler Lambda Handler zugeordnet ist.

4) SnapStart aktiviert mit API Gateway-Anforderungsaufruf-Priming/Proxying

Verwenden Sie in template.yaml die folgende Konfiguration:

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

und wir müssen die Lambda-Funktion mit dem Namen aufrufen
GetProductByIdWithSpringBoot32SCFAndWebRequestPriming, das der Java-Klasse GetProductByIdWithWebRequestPrimingHandler Lambda Handler zugeordnet ist.

Abkürzung c steht für Kaltstart und w steht für Warmstart.

Kalte (c) und warme (w) Startzeit in ms:

Abschluss

Durch die Aktivierung von SnapStart allein für die Lambda-Funktion wird die Kaltstartzeit der Lambda-Funktion erheblich verkürzt. Durch die zusätzliche Verwendung des DynamoDB-Aufrufprimings können wir Kaltstarts erzielen, die nur geringfügig höher sind als die Kaltstarts, die in meinem Artikel „AWS SnapStart – Messen von Kalt- und Warmstarts mit Java 21 unter Verwendung unterschiedlicher Speichereinstellungen“ beschrieben werden, in dem wir Kalt- und Warmstarts für das reine Lambda gemessen haben funktioniert ohne die Verwendung von Frameworks einschließlich der 1024-MB-Speichereinstellung wie in unserem Szenario.

Beim Vergleich der Kalt- und Warmstartzeiten, die wir mit AWS Serverless Java Container im Artikel Messen von Kalt- und Warmstarts mit AWS Serverless Java Container und Messen von Kalt- und Warmstarts mit AWS Lambda Web Adapter gemessen haben, stellen wir fest, dass die Spring Cloud-Funktion höhere Kaltstarts bietet Startzeiten als AWS Lambda Web Adaptor, aber durchaus vergleichbare Kaltstartzeiten wie AWS Serverless Java Container (Ergebnisse variieren leicht je nach Perzentil). In Bezug auf die Warmstart-/Ausführungszeiten erzielen alle drei Ansätze durchaus vergleichbare Ergebnisse, insbesondere wenn man sich die Perzentile unter 99,9 ansieht.