AWS SnapStart - Partie Mesure des démarrages à froid et à chaud avec Java à l'aide de la couche Lambda (2)-javaDidacticiel-php.cn

AWS SnapStart - Part Measuring cold and warm starts with Java using Lambda layer (2)

Introduction

Dans l'article de blog Comment créer, publier et utiliser des couches pour les fonctions Java 21 Lambda, nous avons expliqué comment publier notre première couche Lambda avec Java 21. Dans l'article Mesurer les démarrages à froid et à chaud avec Java 21 à l'aide de la couche Lambda (1) nous avons créé l'application à l'aide de cette couche Lambda, puis mesuré les temps de démarrage à froid et à chaud sans SnapStart activé, avec SnapStart activé et également appliqué l'optimisation de l'amorçage des invocations DynamoDB et comparé les résultats avec nos mesures sans utiliser les couches Lambda et en fournissant toutes les dépendances dans le fichier POM. ce que nous avons fait dans l'article Mesurer les démarrages à froid et à chaud avec Java 21 en utilisant différents paramètres de mémoire Lambda. Dans cet article, nous allons créer une autre couche Lambda avec toutes les dépendances et utiliser cette couche dans notre application, effectuer les mêmes mesures et comparer le résultat avec l'expérience précédente.

La mesure du froid et du chaud commence avec Java 21 en utilisant la couche Lambda avec toutes les dépendances

Par souci d'exploration, nous utiliserons l'exemple de couche Lambda pour créer la couche Lambda avec le runtime Java 21 en empaquetant toutes dépendances dans la couche :

dynamodb
lambda
client-Apache
aws-lambda-java-core
aws-lambda-java-events
org-crac
slf4j-simple
jackson-dataformat-xml

Nous utiliserons également l’exemple d’application. Il existe essentiellement 2 fonctions Lambda définies dans le modèle AWS SAM qui répondent toutes deux aux requêtes API Gateway et récupèrent le produit par identifiant reçu de l'API Gateway de DynamoDB. Une fonction Lambda GetProductByIdWithPureJava21LambdaWithAllLayer peut être utilisée avec et sans SnapStart et la seconde GetProductByIdWithPureJava21LambdaAndPrimingWithAllLayer utilise l'amorçage d'appel de requête SnapStart et DynamoDB.

Afin d'utiliser la couche Lambda avec toutes les dépendances créées précédemment pour les fonctions Lambda dans le modèle AWS SAM, nous devons ajouter le paramètre Layers à la fonction Lambda comme ceci :

    Type: AWS::Serverless::Function
    Properties:
      FunctionName: GetProductByIdWithPureJava21LambdaWithAllLayer
      AutoPublishAlias: liveVersion
      Layers:
        - !Sub arn:aws:lambda:${AWS::Region}:${AWS::AccountId}:layer:aws-pure-java-21-common-lambda-layer:1
      Handler: software.amazonaws.example.product.handler.GetProductByIdHandler::handleRequest

Copier après la connexion

Veuillez remplacer l'ARN de la couche (y compris la version) par le vôtre qui est le résultat de la commande de publication de couche (aws lambda submit-layer-version).

Dans pom.xml, vous voyez toutes les dépendances avec la portée fournie (par la couche Lambda attachée).

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.
J'ai exécuté toutes ces expériences en donnant à nos fonctions Lambda 1024 Mo de mémoire et en passant l'option de compilation suivante via la variable d'environnement : JAVA_TOOL_OPTIONS : "-XX:+TieredCompilation -XX:TieredStopAtLevel=1" (compilation client sans profilage).

Dans les tableaux ci-dessous, je fournirai également les résultats avec nos mesures sans utiliser les couches Lambda (et en fournissant toutes les dépendances dans le fichier POM) comme nous l'avons fait dans l'article Mesurer les démarrages à froid et à chaud avec Java 21 en utilisant différentes mémoire Lambda paramètres et les mesures lors de l'utilisation de la couche Lambda commune pour avoir directement la comparaison.
L'abréviation c est pour le démarrage à froid et w est pour le démarrage à chaud.

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

Experiment	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
with all dependencies Lambda Layer	2824.33	2884.24	2963.14	3324.07	3622.44	3625.58	5.50	6.20	7.16	15.50	46.19	1278.41
with common Lambda Layer	3497.91	3597.18	3695.58	3800.47	3908.33	4011.71	5.82	6.72	8.00	17.97	55.48	1709.13
w/o Lambda Layer	3157.6	3213.85	3270.8	3428.2	3601.12	3725.02	5.77	6.50	7.81	20.65	90.20	1423.63

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

Experiment	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
with all dependencies Lambda Layer	1706.64	1767.40	1893.59	2314.91	2646.68	2647.33	5.59	6.25	7.21	15.75	48.06	1403.71
with common Lambda Layer	2047.12	2124.24	2439.49	2705.52	2735.43	2831.59	5.68	6.40	7.45	17.06	48.45	2139.74
w/o Lambda Layer	1626.69	1741.10	2040.99	2219.75	2319.54	2321.64	5.64	6.41	7.87	21.40	99.81	1355.09

Heures de démarrage à froid (c) et à chaud (w) avec SnapStart et avec invocation DynamoDB Priming en ms :

Experiment	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
with all dependencies Lambda Layer	747.47	786.56	932.23	1099.38	1666.18	1666.62	5.42	5.91	7.39	16.39	45.09	574.61
with common Lambda Layer	713.88	766.38	1141.94	1181.41	1214.94	1215.32	5.59	6.30	7.39	16.39	45.09	574.61
w/o Lambda Layer	702.55	759.52	1038.50	1169.66	1179.05	1179.36	5.73	6.51	7.87	21.75	92.19	328.41

Conclusion

Dans cet article, nous avons créé l'application en utilisant la couche Lambda avec toutes les dépendances, puis avons mesuré les temps de démarrage à froid et à chaud sans SnapStart activé, avec SnapStart activé et avons également appliqué l'optimisation de l'amorçage des invocations DynamoDB et comparé les résultats avec nos mesures sans utiliser Lambda. couches (et en fournissant toutes les dépendances dans le fichier POM), ce que nous avons fait dans l'article Mesurer les démarrages à froid et à chaud avec Java 21 en utilisant différents paramètres de mémoire Lambda et en utilisant une couche Lambda commune.

Même si j'ai eu quelques écarts dans les résultats mais la tendance était toujours la même après plusieurs mesures utilisant la couche Lambda avec toutes les dépendances :

Lorsque SnapStart n'était pas activé, le démarrage à froid avec cette couche Lambda était jusqu'à plusieurs centaines de millisecondes inférieur à celui sans utilisation de la couche Lambda pour des centiles jusqu'à p90 (ce qui m'a surpris).
Lors de l'activation de SnapStart mais n'utilisant pas l'amorçage de la requête DynamoDB, les démarrages à froid variaient en faveur de la couche Lambda avec toutes les dépendances ou en faveur de la Lambda qui n'utilise pas du tout de couches Lambda en fonction du centile.
Lors de l'utilisation de SnapStart avec l'amorçage de la requête DynamoDB, les démarrages à froid étaient proches pour les deux cas d'utilisation pour les percentiles jusqu'à p99, puis plus élevés pour p99.9 et supérieurs lors de l'utilisation de la couche Lambda avec toutes les dépendances. Ainsi, les résultats variaient beaucoup pour chaque cas d’utilisation. Ce que j'ai toujours observé, c'est que la plage des résultats était assez grande (différence de 800 à 900 ms entre les valeurs p50 et maximales) pour toutes les mesures lors de l'utilisation de la couche Lambda avec toutes les dépendances et la même plage était beaucoup plus faible lorsque l'on n'utilisait pas du tout les couches Lambda.
En comparant les mesures de cet article avec les mesures avec une couche Lambda commune, nous observons que nous avons obtenu des démarrages à froid inférieurs pour l'utilisation de toutes les dépendances dans les couches Lambda pour les 2 premières expériences (pas de SnapStart activé et SnapStart activé mais aucun amorçage appliqué) et vice-versa. lorsque SnapStart est activé et que l'appel DynamoDB est initialisé.
Les temps de démarrage/exécution à chaud de la fonction Lambda étaient assez proches pour tous les cas d'utilisation.

Donc, l'utilisation des couches Lambda (en fonction de ce que vous y mettez et de ce que vous expédiez en tant que dépendance dans votre application) ajoute une certaine imprévisibilité et vous devez toujours faire vos propres mesures !

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!