Spring Boot-Anwendung auf AWS Lambda – Teil Die Messung von Kalt- und Warmstarts erfolgt mit der Spring Cloud-Funktion

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 das Netzwerk zu durchlaufen . 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 Erklärung, 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“ erläutert

Resourcedes CraC-Projekts.

Core.getGlobalContext().register(this);

beforeCheckpointaus der CRaC-API implementieren.

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

Resourcewie 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 Aufrufvorbereitung.

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

beforeCheckpoint, wenn die gesamte API-Gateway-Anfrage vorbereitet (Proxy) wird, ohne das Netzwerk zu durchlaufen, mithilfe der Spring Cloud Function-KlasseFunctionInvoker, die ihre handleRequest-Methode aufruft, indem sie den Eingabestrom der oben aufgebauten API-Gateway-JSON-Anfrage wie folgt übergibt:

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

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

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

3) SnapStart aktiviert mit DynamoDB-Aufrufvorbereitung

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

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

and we need to invoke Lambda function with name
GetProductByIdWithSpringBoot32SCFAndWebRequestPriming which is mapped to the GetProductByIdWithWebRequestPrimingHandler Lambda Handler Java class.

Abbreviationcis for the cold start andwis for the warm start.

Cold (c) and warm (w) start time in ms:

Conclusion

By enabling SnapStart on the Lambda function alone, it reduces the cold start time of the Lambda function significantly. By additionally using DynamoDB invocation priming we are be able to achieve cold starts only slightly higher than cold starts described in my article AWS SnapStart -Measuring cold and warm starts with Java 21 using different memory settings where we measured cold and warm starts for the pure Lambda function without the usage of any frameworks including 1024MB memory setting like in our scenario.

Comparing the cold and warm start times we measured with AWS Serverless Java Container in the article Measuring cold and warm starts with AWS Serverless Java Container and Measuring cold and warm starts with AWS Lambda Web Adapter we observe that Spring Cloud Function offers higher cold start times than AWS Lambda Web Adapter but quite comparable cold start times to AWS Serverless Java Container (results vary slightly depending on the percentiles). In terms of warm start/execution times all 3 approaches have quite comparable results when especially looking into the percentiles below 99.9.

Das obige ist der detaillierte Inhalt vonSpring Boot-Anwendung auf AWS Lambda – Teil Die Messung von Kalt- und Warmstarts erfolgt mit der Spring Cloud-Funktion. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!