Performances AWS Lambda avec Java xvs arm - Mesures initiales

Introduction

Jusqu'à présent, je n'ai pas mesuré les performances (temps de démarrage à chaud et à froid) des fonctions Lambda à l'aide du runtime Java 21 pour certains cas d'utilisation (comme faire une requête DynamoDB) pour l'architecture arm64 car elle ne prend pas en charge SnapStart. Lambda avec le runtime Java 21 avec une architecture x86_64 avec SnapStart activé surpassera (encore plus avec une optimisation d'amorçage supplémentaire) Lambda avec une architecture arm64. Mais le 18 juillet 2024, AWS a annoncé qu'AWS Lambda prend désormais en charge SnapStart pour les fonctions Java qui utilisent l'architecture ARM64. Il était donc logique pour moi de commencer à mesurer les temps de démarrage à froid et à chaud, en tenant également compte du choix de l'architecture de la fonction Lambda. On sait qu'avec le paramètre actuel de tarification de la mémoire et la durée d'exécution d'AWS Lambda, Lambda avec l'architecture arm64 sera d'env. 25 % moins cher que Lambda avec une architecture x86_64.

J'ai décidé de créer une série d'articles distincte à cet effet et de ne pas ajouter ce sujet à ma série AWS Lambda SnapStart en constante évolution.

Mesure des démarrages à froid et à chaud pour l'exemple d'application

Dans notre expérience, nous réutiliserons l'application présentée dans l'article AWS Lambda SnapStart - Mesure des démarrages à froid de Java 21 Lambda. Voici le code de l’exemple d’application. Il existe essentiellement 2 fonctions Lambda principales qui répondent toutes deux aux requêtes API Gateway pour créer le produit avec l'identifiant donné (voir la fonction Lambda PutProductFunction) et récupérer le produit par l'identifiant donné (voir la fonction Lambda GetProductByIdFunction). Vous pouvez utiliser les deux fonctions Lambda avec et sans SnapStart activé. Il existe une fonction Lambda supplémentaire GetProductByIdWithPrimingFunction que j'ai écrite pour mesurer indépendamment l'effet de l'amorçage des requêtes DynamoDB pour la fonction Lambda activée par SnapStart. Vous pouvez en savoir plus sur l'effet de l'amorçage dans mon article AWS Lambda SnapStart - Mesurer l'amorçage, la latence de bout en bout et le temps de déploiement .

Pour activer SnapStart sur toutes les fonctions Lambda, veuillez décommenter ce qui suit dans le modèle SAM :

Globals:
  Function:
    CodeUri: target/aws-pure-lambda-snap-start-21-1.0.0-SNAPSHOT.jar
    ...
    SnapStart:
     ApplyOn: PublishedVersions  
   ...

Si je souhaite utiliser SnapStart uniquement pour les fonctions individuelles, mais pas pour toutes les fonctions Lambda, vous devez appliquer cette définition SnapStart au niveau de la fonction Lambda au lieu du niveau de la fonction globale.

Toutes les fonctions Lambda ont les paramètres suivants comme point de départ :

• Paramètre de mémoire de 1 024 Mo
• Client HTTP Apache par défaut utilisé pour communiquer avec la base de données DynamoDB
• Option de compilation Java "-XX:+TieredCompilation -XX:TieredStopAtLevel=1" qui s'est avérée offrir un très bon compromis entre les heures de démarrage à froid et à chaud

Dans le modèle SAM, j'ai ajouté la possibilité de définir l'architecture Lambda dans la section globale des fonctions Lambda comme :

Globals:
  Function:
    CodeUri: target/aws-pure-lambda-snap-start-21-1.0.0-SNAPSHOT.jar
    ...
    Architectures:
      #- arm64
      - x86_64   

Décommentez simplement l'architecture que vous souhaitez utiliser pour vos fonctions Lambda.

Même si Java signifie "écrire une fois, exécuter partout", j'ai quand même compilé et construit le fichier jar d'application pour mes mesures arm64 sur l'instance t4g AWS EC2 avec le processeur Graviton (qui est basé sur l'architecture arm64/aarch64) en installant au préalable Amazon Corretto 21 pour Linux aarch64. Vous pouvez trouver ce pot ici.

J'ai également tout re-mesuré pour l'architecture x86_64 une fois de plus pour obtenir des résultats comparables en utilisant la même dernière version d'exécution de Corretto Java 21 qui, au moment de mes mesures, était Java 21.v17 .

Les résultats de l'expérience ci-dessous étaient basés sur la reproduction de plus de 100 démarrages à froid et d'environ 100 000 démarrages à chaud. Pour cela (et pour les expériences de mon article précédent), j'ai utilisé l'outil de test de charge, mais vous pouvez utiliser l'outil de votre choix, comme Serverless-artillerie ou Postman. Il est également important de savoir que j'ai commencé les mesures juste après le nouveau (re)déploiement du code source de l'application. Veuillez noter qu'il y a également un impact du cache hiérarchisé par instantané sur les démarrages à froid, où les premières invocations sont généralement plus lentes, et les suivantes deviennent plus rapides jusqu'à ce qu'un certain nombre d'invocations soit atteint.

Mettons maintenant toutes les mesures pour "obtenir le produit par identifiant existant" (fonctions Lambda GetProductByIdFunction et GetProductByIdWithPrimingFunction pour SnapStart activé et mesures d'amorçage) ensemble.

Heure de démarrage à froid (c) et à chaud (m) en ms :

Approach	c p50	c p75	c p90	c p99	c p99.9	c max	w p50	w p75	w p90	w p99	w p99.9	w max
x86_64, no SnapStart enabled	3554.30	3615.21	3666.15	3800.47	4108.61	4111.78	5.42	6.01	6.88	14.09	40.98	1654.59
arm64, no SnapStart enabled	3834.81	3904.42	3983.26	4047.47	4332.13	4335.74	5.96	6.66	7.69	16.01	43.68	1844.54
x86_64, SnapStart enabled without priming	1794.09	1846.86	2090.54	2204.27	2239.80	2240.08	5.37	5.96	6.93	15.88	51.64	1578.34
arm64, SnapStart enabled without priming	1845.01	1953.18	2591.70	2762.91	2793.45	2795.8	5.91	6.56	7.63	16.75	63.52	1779.14
x86_64, SnapStart enabled with DynamoDB request priming	803.18	870.18	1103.78	1258.19	1439.95	1440.67	5.55	6.25	7.45	15.50	63.52	448.85
arm64, SnapStart enabled with DynamoDB request priming	910.14	1001.79	1376.62	1623.44	1684.60	1686.19	6.05	6.72	7.81	16.66	74.68	550.59

Conclusion

Dans cet article, nous avons comparé les mesures des heures de démarrage à froid et à chaud de la fonction Lambda se connectant à la base de données DynamoDB pour 3 cas d'utilisation :

• sans SnapStart activé sur la fonction Lambda
• avec SnapStart activé sur la fonction Lambda mais sans optimisation d'amorçage
• avec SnapStart activé sur la fonction Lambda et avec amorçage de la requête DynamoDB

Nous avons constaté qu'en utilisant l'architecture x86_64, tous les temps de démarrage à froid et à chaud étaient inférieurs à ceux de l'architecture arm64. Mais comme le prix Lambda de l'architecture arm64 est 25 % moins cher que l'architecture x86_64 , il introduit un compromis coût-performance très intéressant.

Pour nos mesures, pour les 3 cas d'usage :

• Les temps de démarrage à froid Lambda avec l'architecture arm64 étaient pour de nombreux centiles seulement 10 à 20 % (et seulement dans de très rares cas, 25 à 27 %) plus lents par rapport à l'architecture x86_64.
• Les temps de démarrage à chaud Lambda avec l'architecture arm64 étaient pour de nombreux percentiles seulement 5 à 10 % plus lents par rapport à l'architecture x86_64.

Ainsi, le choix de l'architecture arm64 est tout à fait raisonnable pour cet exemple d'application. Comme la prise en charge de SnapStart pour l'architecture arm64 n'a été introduite que récemment, je m'attends également à des améliorations de performances à l'avenir. Veuillez effectuer vos propres mesures pour votre cas d'utilisation !

Dans la prochaine partie de l'article, nous effectuerons les mêmes mesures de performances mais en réglant la mémoire Lambda sur des valeurs différentes entre 256 et 2048 Mo et comparerons les résultats.

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!