API de données pour Amazon Aurora Serverless avec AWS SDK pour Java - Stratégies de optimisation partielle pour les démarrages à froid et à chaud

Introduction

Dans les articles précédents de la série sur la façon de se connecter à Amazon Aurora Serverless v2 à partir de la fonction Lambda avec l'API Data et le SDK AWS pour Java, nous avons effectué des mesures de base de démarrages à froid et à chaud, comparé les démarrages à froid et à chaud entre l'API Data et JDBC. et effet mesuré avec SnapStart avec et sans amorçage.

Dans cette partie de la série, nous présenterons des stratégies d'optimisation pour les démarrages à froid et à chaud.

Stratégies d'optimisation pour les démarrages à froid et à chaud

Pour trouver un bon équilibre entre les heures de démarrage à froid et à chaud, vous pouvez essayer les techniques d'optimisation présentées ci-dessous. Je n'ai effectué aucune mesure avec ceux utilisant l'API Data et Amazon Aurora Serverless v2 avec la base de données PostgreSQL, mais avec un scénario similaire utilisant la base de données DynamoDB à la place. Je fournirai des références à mes articles pertinents.

• Essayez différents paramètres de mémoire Lambda. Jusqu'à présent, toutes les mesures ont été effectuées avec 1024 Mo de mémoire pour la fonction Lambda. Avec différents paramètres de mémoire, vous pourriez obtenir de meilleures performances à un prix justifiable. Voir mon article Mesurer les démarrages à froid et à chaud et le temps de déploiement avec Java 21 à l'aide de différents paramètres de mémoire Lambda pour des explications sur les mesures avec DynamoDB.
• Essayez différentes options de compilation Java pour la fonction Lambda. Jusqu'à présent, toutes les mesures ont été effectuées avec l'option de compilation "-XX:+TieredCompilation -XX:TieredStopAtLevel=1" pour la fonction Lambda. D'autres options peuvent être fournies à la fonction Lambda à l'aide d'une variable d'environnement appelée JAVA_TOOL_OPTIONS qui peut avoir différents compromis de démarrage à froid et à chaud. Voir mon article Mesurer le froid et le chaud démarre avec Java 21 en utilisant différentes options de compilation pour des explications sur les mesures avec DynamoDB.
• Essayez différents clients HTTP synchrones pour établir une connexion HTTP à la base de données via l'API Data. Jusqu'à présent, toutes les mesures ont été effectuées avec le client HTTP synchrone par défaut qui est Apache. Il existe d'autres options telles que les clients HTTP UrlConnection et AWS CRT qui offrent différents compromis de performances pour les démarrages à froid et à chaud.

Voici un exemple d'utilisation du client HTTP AWS CRT lors de la création/construction du RdsDataClient. Le client URLConnection peut être défini de la même manière.

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

N'oubliez pas non plus d'inclure la dépendance du client HTTP utilisé au pom.xml comme ceci :

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

Voir mon article Mesurer le froid et le chaud démarre avec Java 21 en utilisant différents clients HTTP synchrones pour des explications, des exemples de code et des mesures avec DynamoDB.

• Découvrez si le client HTTP asynchrone pour l'API de données est une option pour votre cas d'utilisation. Le client HTTP asynchrone par défaut est NettyNio. Il existe une autre option de client HTTP asynchrone AWS CRT qui offre différents compromis de performances pour les démarrages à froid et à chaud.

Voici un exemple d'utilisation du client HTTP AWS CRT asynchrone lors de la création/construction du RdsDataAsyncClient (que nous devons créer en cas d'utilisation d'un client HTTP asynchrone).

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

N'oubliez pas non plus d'inclure la dépendance du client HTTP utilisé au pom.xml comme ceci :

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

Dans ce cas, nous devons utiliser le modèle de programmation asynchrone Java (qui est le sujet de discussion en soi) et donc chaque invocation de méthode sur RDSDataAsyncClient renverra l'objet Java CompletableFuture. Voir mon article Mesurer les démarrages à froid et à chaud avec Java 21 à l'aide de différents clients HTTP asynchrones pour des explications, des exemples de code et des mesures avec DynamoDB.

Pour toutes les stratégies d'optimisation potentielles, vous pouvez activer SnapStart sur la fonction Lambda et mesurer en outre l'impact de l'amorçage des invocations DynamoDB comme décrit dans l'article précédent L'API de données rencontre SnapStart de la série.

Soyez également conscient de l'impact du cache hiérarchisé par instantané sur les démarrages à froid que j'ai décrit dans mon article. Comme je fournis toujours des mesures de démarrage à froid pour les premiers 100 démarrages à froid après le déploiement de la nouvelle version de la fonction Lambda. Avec le cache hiérarchisé utilisé, j'ai mesuré et décrit que le démarrage à froid diminue considérablement avec davantage d'appels ultérieurs. Après un certain nombre d'appels, il reste alors constant pour la version Lambda spécifique.

Conclusion

Dans cet article, nous avons fourni des stratégies d'optimisation pour les démarrages à froid et à chaud à l'aide de l'API de données pour Amazon Aurora Serverless v2 avec AWS SDK pour Java que vous pouvez explorer pour découvrir les meilleures performances pour votre propre cas d'utilisation.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!