Dans le premier article de notre petite série, nous avons exploré comment développer et déployer la fonction Lambda à l'aide de Docker Container Image et du runtime Java. Nous avons exploré 2 cas d'utilisation :
Dans cet article, nous mesurerons les démarrages à froid et à chaud de la fonction Lambda en utilisant cette approche Image du conteneur Docker de base AWS Lambda.
Pour nos mesures, nous utiliserons notre exemple d'application de la première partie et utiliserons le runtime Java 21 pour nos fonctions Lambda. Pour toutes les fonctions Lambda, nous accordons 1 024 Mo de mémoire et utilisons JAVA_TOOL_OPTIONS : "-XX:+TieredCompilation -XX:TieredStopAtLevel=1" car cette option de compilation offre un très bon échange entre les heures de démarrage à froid et à chaud.
Les résultats de l'expérience ci-dessous étaient basés sur la reproduction de plus de 100 démarrages à froid et environ 100 000 démarrages à chaud pendant une heure avec la fonction Lambda GetProductByIdWithPureJava21GraalVMNativeImageLambda qui est mappée à la classe de gestionnaire Java Lambda qui est responsable de la récupération du produit (stocké dans DynamoDB) par identifiant. Pour cela, j'ai utilisé l'outil de test de charge, mais vous pouvez utiliser l'outil de votre choix, comme Serverless-artillerie ou Postman.
Heure de démarrage à froid (c) et à chaud (m) en ms :
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 |
---|---|---|---|---|---|---|---|---|---|---|---|
3093.26 | 3219.44 | 3314.12 | 4632.16 | 6513.35 | 6517.71 | 5.47 | 6.20 | 7.39 | 17.14 | 43.03 | 1386.07 |
Dans cet article, nous avons mesuré les heures de démarrage à froid et à chaud de la fonction Lambda en utilisant cette approche Image du conteneur Docker de base AWS Lambda. Nous avons connu des démarrages à froid assez importants et des temps de démarrage à chaud assez compétitifs par rapport à la mesure des démarrages à froid et à chaud avec Java 21 en utilisant différents paramètres de mémoire Lambda pour Lambda avec 1 024 Mo de mémoire et un runtime géré Lambda Java 21.
AWS Lambda SnapStart, qui réduit considérablement les temps de démarrage à froid, n'est actuellement disponible que pour les environnements d'exécution gérés Java Corretto (11, 17 et 21) et non pour les images de conteneurs Docker. Vous pouvez explorer l'outil jlink pour assembler et optimiser un ensemble de modules et leurs dépendances dans une image d'exécution personnalisée plus petite et un partage de données de classe (CDS), ce qui permet de réduire le temps de démarrage des applications du langage de programmation Java, en particulier des applications plus petites, ainsi que réduire l’empreinte. L'avantage d'utiliser l'image Docker comme artefact de déploiement pour Java est la possibilité d'utiliser un runtime Java récent comme Java 22 (Java 23 sera publié en septembre 2024).
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!