Introducción

En la parte 7 de la serie API de datos para Amazon Aurora Serverless v2 con AWS SDK para Java: la API de datos se encuentra con SnapStart, medimos los tiempos de inicio en frío y en caliente de la función Lambda que se conecta a la base de datos PostgreSQL de Amazon Aurora Serverless v2 mediante datos API para 3 casos de uso:

• sin SnapStart habilitado en la función Lambda
• con SnapStart habilitado en la función Lambda pero sin optimización de cebado
• con SnapStart habilitado en la función Lambda y con optimización de priming (ejecución de sentencias SQL de precalentamiento en la base de datos PostgreSQL).

En este artículo nos gustaría comparar esas mediciones con aquellas, pero usando DynamoDB en lugar de Data API para Amazon Aurora Serverless v2.

Comparación de arranques en frío y en caliente de Lambda: API de datos para Amazon Aurora Serverless v2 frente a DynamoDB

En mi serie de artículos sobre Lambda SnapStart ya hemos realizado este tipo de mediciones para aplicaciones similares, pero en el artículo Medición de arranques en caliente con Java 21 usando diferentes configuraciones de memoria Lambda.

Ambas aplicaciones Data API para Amazon Aurora Serverless v2 y DynamoDB son muy similares :

• Proporcionan lógica para almacenar y recuperar productos de la base de datos
• Las funciones Lambda de ambos proyectos tienen una configuración de memoria de 1024 MB
• El tamaño de los artefactos de implementación es de alrededor de 18 MB para ambos
• Las funciones Lambda de ambos proyectos utilizan el cliente Apache HTTP síncrono predeterminado para comunicarse con las bases de datos
• Las funciones Lambda de ambos proyectos usan arquitectura x86_64

Ahora juntemos todas las medidas.

Hora de inicio en frío (c) y calor (m) en ms:

Conclusión

En este artículo, comparé las mediciones de los tiempos de inicio en frío y en caliente de la función Lambda que se conecta a la base de datos PostgreSQL de Amazon Aurora Serverless v2 mediante Data API con la conexión a la base de datos DynamoDB para 3 casos de uso:

• sin SnapStart habilitado en la función Lambda
• con SnapStart habilitado en la función Lambda pero sin optimización de cebado
• con SnapStart habilitado en la función Lambda y con preparación de la solicitud de base de datos

Lo que observamos es que los tiempos de inicio en frío sin habilitar SnapStart en la función Lambda son bastante comparables para ambos. En caso de que SnapStart esté habilitado (sin y especialmente con preparación), la API de datos para Amazon Aurora Serverless v2 tiene tiempos de inicio en frío significativamente más altos, especialmente para los percentiles >= 90. Tendré que profundizar más para comprender esta diferencia, ya que no lo hice. Espere que sea tan grande, especialmente si se aplicó imprimación. Quizás la razón es que los servicios nativos de AWS como DynamoDB son más compatibles con SnapStart y puedo manejar mejor las reanudaciones de conexión.

Los tiempos de inicio en caliente (ejecución) fueron constantemente mucho más altos para Data API para Amazon Aurora Serverless v2 en comparación con DynamoDB, lo cual también esperaba, ya que DynamoDB es conocido por sus tiempos de respuesta de milisegundos de uno o dos dígitos.