Introduction

Dans la partie 7 de la série Data API for Amazon Aurora Serverless v2 with AWS SDK for Java - Data API meets SnapStart, nous avons mesuré les heures de démarrage à froid et à chaud de la fonction Lambda se connectant à la base de données PostgreSQL Amazon Aurora Serverless v2 à l'aide de Data API pour 3 cas d'usage :

• 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 optimisation d'amorçage (préchauffage de l'exécution des instructions SQL sur la base de données PostgreSQL).

Dans cet article, nous aimerions comparer ces mesures avec celles, mais en utilisant DynamoDB au lieu de l'API de données pour Amazon Aurora Serverless v2.

Comparaison des démarrages à froid et à chaud de Lambda : API de données pour Amazon Aurora Serverless v2 et DynamoDB

Dans ma série d'articles sur Lambda SnapStart, nous avons déjà effectué de telles mesures pour une application similaire, mais dans l'article Mesurer les démarrages à chaud avec Java 21 en utilisant différents paramètres de mémoire Lambda.

Les deux applications Data API pour Amazon Aurora Serverless v2 et DynamoDB sont très similaires :

• Ils fournissent une logique pour stocker et récupérer les produits de la base de données
• Les fonctions Lambda des deux projets ont un paramètre de mémoire de 1 024 Mo
• La taille des artefacts de déploiement est d'environ 18 Mo pour les deux
• Les fonctions Lambda des deux projets utilisent le client HTTP Apache synchrone par défaut pour communiquer avec les bases de données
• Les fonctions Lambda des deux projets utilisent l'architecture x86_64

Rassemblons maintenant toutes les mesures.

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

Conclusion

Dans cet article, j'ai comparé les mesures des heures de démarrage à froid et à chaud de la fonction Lambda se connectant à la base de données Amazon Aurora Serverless v2 PostgreSQL à l'aide de l'API Data et la connexion à 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 base de données

Ce que nous avons observé, c'est que les temps de démarrage à froid sans activer SnapStart sur la fonction Lambda sont tout à fait comparables pour les deux. Dans le cas où SnapStart est activé (sans et surtout avec amorçage), l'API de données pour Amazon Aurora Serverless v2 a des temps de démarrage à froid nettement plus élevés, en particulier pour les centiles >= 90. Je devrai creuser plus profondément pour comprendre cette différence car je ne l'ai pas fait. attendez-vous à ce qu'il soit aussi gros, surtout si un apprêt a été appliqué. La raison en est peut-être que les services natifs AWS comme DynamoDB sont davantage conscients de SnapStart et je peux mieux gérer les reprises de connexion.

Les temps de démarrage à chaud (exécution) étaient constamment beaucoup plus élevés pour l'API de données pour Amazon Aurora Serverless v2 par rapport à DynamoDB, ce à quoi je m'attendais également car DynamoDB est connu pour ses temps de réponse à un ou deux chiffres en millisecondes.