Introducción

Hasta ahora no he medido el rendimiento (tiempos de inicio en caliente y en frío) de las funciones Lambda usando el tiempo de ejecución de Java 21 para algunos casos de uso (como realizar solicitudes de DynamoDB) para la arquitectura arm64 porque no es compatible con SnapStart. Lambda con el tiempo de ejecución de Java 21 con arquitectura x86_64 con SnapStart habilitado superará (aún más con optimización de preparación adicional) a Lambda con arquitectura arm64. Pero el 18 de julio de 2024, AWS anunció que AWS Lambda ahora admite funciones SnapStart para Java que utilizan la arquitectura ARM64. Así que ahora tenía sentido para mí comenzar a medir los tiempos de arranque en frío y en caliente, considerando también la elección de la arquitectura de la función Lambda. Se sabe que con la configuración actual de la memoria de precios de AWS Lambda y la duración de ejecución, Lambda con arquitectura arm64 será de aprox. 25% más barato que Lambda con arquitectura x86_64.

Decidí crear una serie de artículos separada y no agregar este tema a mi serie cada vez mayor de AWS Lambda SnapStart.

Medición de los arranques en frío y en caliente para la aplicación de ejemplo

En nuestro experimento reutilizaremos la aplicación presentada en el artículo AWS Lambda SnapStart: medición de arranques en frío de Java 21 Lambda. Aquí está el código de la aplicación de muestra. Básicamente, existen 2 funciones Lambda principales que responden a las solicitudes de API Gateway para crear el producto con la identificación dada (consulte la función Lambda PutProductFunction) y recuperan el producto mediante la identificación dada (consulte la función Lambda GetProductByIdFunction). Puede utilizar ambas funciones Lambda con y sin SnapStart habilitado. Hay una función Lambda adicional GetProductByIdWithPrimingFunction que escribí para medir de forma independiente el efecto del cebado de solicitudes de DynamoDB para la función Lambda habilitada para SnapStart. Puede leer más sobre el efecto del cebado en mi artículo AWS Lambda SnapStart: medición del cebado, la latencia de extremo a extremo y el tiempo de implementación.

Para habilitar SnapStart en todas las funciones de Lambda, descomente lo siguiente en la plantilla SAM:

Globals:
  Function:
    CodeUri: target/aws-pure-lambda-snap-start-21-1.0.0-SNAPSHOT.jar
    ...
    SnapStart:
     ApplyOn: PublishedVersions  
   ...

Si deseo usar SnapStart solo para las funciones Lambda individuales, pero no para todas, debe aplicar esta definición de SnapStart en el nivel de función Lambda en lugar del nivel de función global.

Todas las funciones Lambda tienen las siguientes configuraciones como punto de partida:

• Configuración de memoria de 1024 MB
• Cliente Apache HTTP predeterminado utilizado para comunicarse con la base de datos de DynamoDB
• Opción de compilación de Java "-XX: TieredCompilation -XX:TieredStopAtLevel=1" que demostró proporcionar una muy buena compensación entre los tiempos de inicio en frío y en caliente

En la plantilla SAM agregué la posibilidad de definir la arquitectura Lambda en la sección de función Lambda global como:

Globals:
  Function:
    CodeUri: target/aws-pure-lambda-snap-start-21-1.0.0-SNAPSHOT.jar
    ...
    Architectures:
      #- arm64
      - x86_64   

Simplemente descomente la arquitectura que le gustaría usar para sus funciones Lambda.

Incluso si Java es "escribir una vez, ejecutar en todas partes", de todos modos compilé y construí el archivo jar de la aplicación para mis mediciones arm64 en la instancia t4g AWS EC2 con el procesador Graviton (que se basa en la arquitectura arm64/aarch64) instalando previamente Amazon Corretto 21 para Linux aarch64. Puedes encontrar este frasco aquí.

También volví a medir todo para la arquitectura x86_64 una vez más para obtener resultados comparables usando la misma última versión de tiempo de ejecución de Corretto Java 21 que en el momento de mis mediciones era Java 21.v17.

Los resultados del siguiente experimento se basaron en la reproducción de más de 100 arranques en frío y aproximadamente 100.000 en caliente. Para ello (y para los experimentos de mi artículo anterior) utilicé la herramienta de prueba de carga, pero puedes usar cualquier herramienta que quieras, como Serverless-artillery o Postman. También es importante tener en cuenta que comencé las mediciones justo después de la (re)implementación del nuevo código fuente de la aplicación. Tenga en cuenta que también existe un impacto de la caché escalonada de instantáneas en los arranques en frío, donde las primeras invocaciones son generalmente más lentas y las siguientes se vuelven más rápidas hasta que se alcanza una cierta cantidad de invocaciones.

Ahora juntemos todas las mediciones para "obtener producto mediante identificación existente" (funciones Lambda GetProductByIdFunction y GetProductByIdWithPrimingFunction para SnapStart habilitado y mediciones de cebado).

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

Conclusión

En este artículo comparamos 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 de 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 DynamoDB

Vimos que al usar la arquitectura x86_64, todos los tiempos de inicio en frío y en caliente eran menores en comparación con la arquitectura arm64. Pero como el precio Lambda de la arquitectura arm64 es un 25% más barato que el de la arquitectura x86_64, introduce una compensación costo-rendimiento muy interesante.

Para nuestras mediciones, para los 3 casos de uso:

• Los tiempos de arranque en frío de Lambda con arquitectura arm64 fueron para muchos percentiles solo entre un 10 y un 20 % (y solo en casos muy raros entre un 25 y un 27 %) más lentos en comparación con la arquitectura x86_64.
• Los tiempos de inicio en caliente de Lambda con la arquitectura arm64 fueron, para muchos percentiles, solo entre un 5 % y un 10 % más lentos en comparación con la arquitectura x86_64.

Por lo tanto, la elección de la arquitectura arm64 es bastante razonable para esta aplicación de muestra. Como la compatibilidad con SnapStart para la arquitectura arm64 se introdujo recientemente, también espero algunas mejoras de rendimiento en el futuro. ¡Haga sus propias medidas para su caso de uso!

En la siguiente parte del artículo haremos las mismas mediciones de rendimiento pero configurando la memoria Lambda en diferentes valores entre 256 y 2048 MB y compararemos los resultados.