Introduction

Dans les parties précédentes de notre série, nous avons mesuré les démarrages à froid de la fonction Lambda avec le runtime Java 21 sans SnapStart activé, avec SnapStart activé et avons également appliqué l'optimisation de l'amorçage des invocations DynamoDB avec différents paramètres de mémoire Lambda, tailles d'artefact de déploiement Lambda, Java options de compilation, (a)clients HTTP synchrones et utilisation de différentes couches Lambda. Pour toutes ces mesures, nous avons utilisé les algorithmes de garbage collection par défaut G1.

Dans cet article, nous aimerions explorer l'impact des algorithmes de garbage collection Java sur les performances de la fonction Lambda avec le runtime Java 21. Nous allons également tout re-mesurer pour que le G1 ait des résultats comparables avec la même version mineure de Java 21 utilisée pour tous les algorithmes de garbage collection.

Algorithmes de récupération de place Java

Pour nos mesures, nous utiliserons les algorithmes de collecte Java suivants avec leurs paramètres par défaut (veuillez vous référer à la documentation liée pour des informations plus détaillées sur chaque algorithme) :

• Récupérateur de déchets Garbage-First (G1). Il s'agit de l'algorithme de garbage collection utilisé par défaut. Vous pouvez le définir explicitement dans le modèle AWS SAM en ajoutant -XX : UseG1GC à la variable d'environnement JAVA_TOOL_OPTIONS.
• Le collecteur parallèle. Vous pouvez le définir explicitement dans le modèle AWS SAM en ajoutant -XX : UseParallelGC à la variable d'environnement JAVA_TOOL_OPTIONS.
• Shenandoah GC. Oracle JDK ne le fournit pas, mais Amazon Corretto 21 JDK le fait. Vous pouvez le définir explicitement dans le modèle AWS SAM en ajoutant -XX : UseShenandoahGC à la variable d'environnement JAVA_TOOL_OPTIONS.
• Le collecteur de déchets Z. Il existe 2 algorithmes ZGC différents : par défaut et le plus récent, une génération. Vous pouvez le définir explicitement dans le modèle AWS SAM en ajoutant -XX : UseZGC ou -XX : UseZGC -XX : ZGenerational à la variable d'environnement JAVA_TOOL_OPTIONS.

La mesure du froid et du chaud démarre avec Java 21 en utilisant différents algorithmes de garbage collection

Dans notre expérience, nous utiliserons une application légèrement modifiée introduite dans la partie 9. Vous pouvez trouver le code de l'application ici. Il existe essentiellement 2 fonctions Lambda qui répondent aux requêtes de l'API Gateway et récupèrent le produit par identifiant reçu de l'API Gateway de DynamoDB. Une fonction Lambda GetProductByIdWithPureJava21LambdaWithGCAlg peut être utilisée avec et sans SnapStart et la seconde GetProductByIdWithPureJava21LambdaAndPrimingWithGCAlg utilise l'amorçage d'appel de requête SnapStart et DynamoDB.

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 avec une expérience qui a duré environ 1 heure. 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. Nous effectuons des expériences en attribuant aux fonctions Lambda 1 024 Mo de mémoire et en utilisant JAVA_TOOL_OPTIONS : "-XX: TieredCompilation -XX:TieredStopAtLevel=1" (compilation client Java sans profilage) qui présente un très bon compromis entre les heures de démarrage à froid et à chaud.

Malheureusement, je n'ai pas pu démarrer la fonction Lambda avec The Z Garbage Collector (avec celui par défaut et générationnel) qui rencontre l'erreur :

Failed to commit memory (Operation not permitted)
[error][gc] Forced to lower max Java heap size from 872M(100%) to 0M(0%)
[error][gc] Failed to allocate initial Java heap (512M)
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

Il a essayé un paramètre de mémoire plus grand, comme 1 024, comme 2 048 Mo, et encore plus, mais la même erreur est toujours apparue.

Examinons les résultats de nos mesures avec 3 autres algorithmes de garbage collection.

Abréviation c désigne le démarrage à froid et w désigne le démarrage à chaud.

Heure de démarrage à froid (c) et à chaud (w) sans SnapStart activé en ms :

Heure de démarrage à froid (c) et à chaud (w) avec SnapStart activé sans amorçage en ms :

Heure de démarrage à froid (c) et à chaud (w) avec SnapStart activé et avec invocation DynamoDB Amorçage en ms :

Conclusion

Dans cet article, nous avons exploré l'impact des algorithmes de garbage collection Java (G1, Parallel Collector et Shenandoah) sur les performances de la fonction Lambda avec le runtime Java 21. Nous avons constaté une grande différence entre les performances de ces algorithmes. En utilisant les paramètres par défaut avec G1 (celui par défaut), nous obtenons (parfois de loin) les temps de démarrage à froid et à chaud les plus bas. En utilisant SnapStart avec l'amorçage de la requête DynamoDB, les résultats de performances sont comme prévu beaucoup plus proches les uns des autres.

Veuillez vous référer à la documentation de chaque algorithme de récupération de place pour régler les paramètres tels que le mixage et la mémoire maximale, ce qui peut apporter une amélioration significative des performances et effectuer vos propres mesures.