Introduction

Dans l'article de blog Comment créer, publier et utiliser des couches pour les fonctions Lambda Java 21, nous avons publié notre première couche Lambda avec Java 21. Dans cet article, nous allons créer l'application à l'aide de cette couche Lambda, puis mesurer le démarrage à froid et à chaud. fois sans SnapStart activé, avec SnapStart activé et également appliqué l'optimisation de l'amorçage des invocations DynamoDB. Nous comparerons é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érents paramètres de mémoire Lambda.

La mesure du froid et du chaud commence avec Java 21 à l'aide de la couche Lambda

Dans notre expérience, nous utiliserons 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 GetProductByIdWithPureJava21LambdaWithCommonLayer peut être utilisée avec et sans SnapStart et la seconde GetProductByIdWithPureJava21LambdaAndPrimingWithCommonLayer utilise l'amorçage d'appel de requête SnapStart et DynamoDB.

Les dépendances fournies via la couche Lambda ont la portée « fournie » dans le fichier pom.xml de notre application.

Afin d'attacher la couche Lambda créée dans l'article Comment créer une publication et utiliser des couches pour les fonctions Lambda Java 21 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: GetProductByIdWithPureJava21LambdaWithCommonLayer
      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

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

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 mené 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) qui fournit un très bon compromis entre les heures de démarrage à froid et à chaud.

Dans les tableaux ci-dessous, je fournirai également les résultats de nos mesures sans utiliser les couches Lambda tirées de l'article Mesurer les démarrages à froid et à chaud avec Java 21 en utilisant différents paramètres de mémoire Lambda pour avoir directement la comparaison entre les deux.
L'abréviation c correspond au démarrage à froid et w correspond au démarrage à chaud.

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

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

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

Conclusion

Dans cet article, nous avons créé l'application à l'aide de la couche Lambda avec des dépendances communes, 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.

J'ai effectué plusieurs fois des mesures en utilisant les couches Lambda communes pour vraiment confirmer le résultat de mon expérience. Même si j'avais quelques écarts dans les résultats entre ces mesures, la tendance était toujours la même : lorsque SnapStart n'était pas activé ou lorsque SnapStart n'était pas activé mais n'était pas utilisé pour l'amorçage de l'invocation DynamoDB, les démarrages à froid avec l'utilisation de Lambda commun La couche était supérieure de plusieurs centaines de millisecondes par rapport au regroupement de toutes les dépendances uniquement dans le fichier POM. Ce n'est que lorsque SnapStart a été activé pour la fonction Lambda et que l'amorçage des appels DynamoDB a été appliqué que les démarrages à froid avec les deux approches étaient très proches, probablement en raison du fait que tout était déjà dans l'instantané créé.

Les démarrages à chaud de la fonction Lambda étaient assez proches pour les deux cas d'utilisation (avec et sans utilisation des couches Lambda) et pour toutes les expériences (avec et sans SnapStart activé) pour presque tous les centiles, mais j'ai toujours obtenu des résultats plus élevés pour la valeur maximale avec l'utilisation de la couche Lambda commune.

Dans le prochain article, je continuerai mes expériences avec les couches Lambda. Cette fois, je vais créer, publier et utiliser la couche Lambda contenant non seulement les dépendances communes (comme dans cet article), mais toutes les dépendances requises pour exécuter cette application, puis comparer les résultats des deux expériences.