Daten-API für Amazon Aurora Serverless mit AWS SDK für Java – Teiloptimierungsstrategien für den Kalt- und Warmstart

Einführung

In den vorherigen Artikeln der Serie über die Verbindung zu Amazon Aurora Serverless v2 über die Lambda-Funktion mit Data API und AWS SDK für Java haben wir grundlegende Kalt- und Warmstartmessungen durchgeführt und Kalt- und Warmstarts zwischen Data API und JDBC verglichen und gemessener Effekt mit SnapStart mit und ohne Grundierung.

In diesem Teil der Serie stellen wir Optimierungsstrategien für den Kalt- und Warmstart vor.

Optimierungsstrategien für den Kalt- und Warmstart

Um ein gutes Gleichgewicht zwischen Kalt- und Warmstartzeiten zu finden, können Sie die unten vorgestellten Optimierungstechniken ausprobieren. Ich habe keine Messungen mit denen durchgeführt, die Data API und Amazon Aurora Serverless v2 mit PostgreSQL-Datenbank verwenden, sondern mit einem ähnlichen Szenario, das stattdessen die DynamoDB-Datenbank verwendet. Ich werde Verweise auf meine relevanten Artikel bereitstellen.

• Probieren Sie verschiedene Lambda-Speichereinstellungen aus. Alle bisherigen Messungen wurden mit 1024 MB Speicher für die Lambda-Funktion durchgeführt. Mit unterschiedlichen Speichereinstellungen erzielen Sie möglicherweise eine bessere Leistung zu einem vertretbaren Preis. Erläuterungen zu Messungen mit DynamoDB finden Sie in meinem Artikel Messen von Kalt- und Warmstarts und Bereitstellungszeit mit Java 21 unter Verwendung verschiedener Lambda-Speichereinstellungen.
• Probieren Sie verschiedene Java-Kompilierungsoptionen für die Lambda-Funktion aus. Alle bisherigen Messungen wurden mit der Kompilierungsoption „-XX:+TieredCompilation -XX:TieredStopAtLevel=1“ für die Lambda-Funktion durchgeführt. Es gibt weitere Optionen, die der Lambda-Funktion über die Umgebungsvariable JAVA_TOOL_OPTIONS bereitgestellt werden können, die unterschiedliche Kalt- und Warmstart-Kompromisse haben können. Siehe meinen Artikel Messung von Kalt- und Warmstarts mit Java 21 unter Verwendung verschiedener Kompilierungsoptionen für Erklärungen zu Messungen mit DynamoDB.
• Probieren Sie verschiedene synchrone HTTP-Clients aus, um über die Daten-API eine HTTP-Verbindung zur Datenbank herzustellen. Alle bisherigen Messungen wurden mit dem standardmäßigen synchronen HTTP-Client Apache durchgeführt. Es gibt andere Optionen wie UrlConnection und AWS CRT HTTP-Clients, die unterschiedliche Leistungskompromisse für den Kalt- und Warmstart bieten.

Dies ist das Beispiel für die Verwendung des AWS CRT-HTTP-Clients beim Erstellen/Aufbauen des RdsDataClient. Der URLConnection-Client kann auf ähnliche Weise eingestellt werden.

RdsDataClient.builder().httpClient(AwsCrtHttpClient.create()).build()

Vergessen Sie auch nicht, die Abhängigkeit vom verwendeten HTTP-Client wie folgt in die pom.xml einzubinden:

     <dependency>
        <groupId>software.amazon.awssdk</groupId>
        <artifactId>aws-crt-client</artifactId>
     </dependency>

Erläuterungen, Codebeispiele und Messungen mit DynamoDB finden Sie in meinem Artikel Messen von Kalt- und Warmstarts mit Java 21 unter Verwendung verschiedener synchroner HTTP-Clients.

• Untersuchen Sie, ob ein asynchroner HTTP-Client für die Daten-API eine Option für Ihren Anwendungsfall ist. Der standardmäßige asynchrone HTTP-Client ist NettyNio. Es gibt eine weitere Option für den asynchronen HTTP-Client AWS CRT, der unterschiedliche Leistungskompromisse für Kalt- und Warmstarts bietet.

Dies ist das Beispiel für die Verwendung des asynchronen AWS CRT-HTTP-Clients beim Erstellen/Aufbauen des RdsDataAsyncClient (den wir erstellen müssen, wenn wir einen asynchronen HTTP-Client verwenden).

RdsDataAsyncClient.builder().httpClient(AwsCrtAsyncHttpClient.create()).build()

Vergessen Sie auch nicht, die Abhängigkeit vom verwendeten HTTP-Client wie folgt in die pom.xml einzubeziehen:

     <dependency>
        <groupId>software.amazon.awssdk</groupId>
        <artifactId>aws-crt-client</artifactId>
     </dependency>

In diesem Fall müssen wir das asynchrone Java-Programmiermodell verwenden (was das Diskussionsthema für sich ist) und daher wird jeder Methodenaufruf auf dem RDSDataAsyncClient ein Java-CompletableFuture-Objekt zurückgeben. Erläuterungen, Codebeispiele und Messungen mit DynamoDB finden Sie in meinem Artikel Messen von Kalt- und Warmstarts mit Java 21 unter Verwendung verschiedener asynchroner HTTP-Clients.

Für alle potenziellen Optimierungsstrategien können Sie SnapStart für die Lambda-Funktion aktivieren und zusätzlich die Auswirkungen des DynamoDB-Aufrufprimings messen, wie im vorherigen Artikel „Daten-API trifft SnapStart“ der Reihe beschrieben.

Beachten Sie auch die Auswirkungen des Snapshot-Tiered-Cache auf die Kaltstarts, die ich in meinem Artikel beschrieben habe. Da ich immer Kaltstartmessungen für die ersten 100 Kaltstarts nach der Bereitstellung der neuen Version der Lambda-Funktion anbiete. Beim Einsatz des Tiered-Cache habe ich gemessen und beschrieben, dass sich der Kaltstart mit mehr nachfolgenden Aufrufen deutlich verringert. Nach einer bestimmten Anzahl von Aufrufen bleibt es dann für die jeweilige Lambda-Version konstant.

Abschluss

In diesem Artikel haben wir Optimierungsstrategien für Kalt- und Warmstarts mithilfe der Daten-API für Amazon Aurora Serverless v2 mit AWS SDK für Java bereitgestellt, die Sie erkunden können, um die beste Leistung für Ihren Anwendungsfall herauszufinden.

Das obige ist der detaillierte Inhalt vonDaten-API für Amazon Aurora Serverless mit AWS SDK für Java – Teiloptimierungsstrategien für den Kalt- und Warmstart. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!