Introducción

En las partes anteriores de nuestra serie, medimos los inicios en frío de la función Lambda con el tiempo de ejecución de Java 21 sin SnapStart habilitado, con SnapStart habilitado y también aplicamos la optimización de preparación de invocación de DynamoDB con diferentes configuraciones de memoria Lambda, tamaños de artefactos de implementación de Lambda, Java opciones de compilación, (a) clientes HTTP sincrónicos y el uso de diferentes capas Lambda. Para todas estas mediciones utilizamos los algoritmos predeterminados de recolección de basura G1.

En este artículo nos gustaría explorar el impacto de los algoritmos de recolección de basura de Java en el rendimiento de la función Lambda con el tiempo de ejecución de Java 21. También volveremos a medir todo para que el G1 tenga resultados comparables con la misma versión menor de Java 21 en uso para todos los algoritmos de recolección de basura.

Algoritmos de recolección de basura de Java

Para nuestras mediciones usaremos los siguientes algoritmos de recopilación de Java con su configuración predeterminada (consulte la documentación vinculada para obtener información más detallada sobre cada algoritmo):

• Recolector de basura Garbage-First (G1). Este es el algoritmo de recolección de basura utilizado por defecto. Puede configurarlo explícitamente en la plantilla de AWS SAM agregando -XX: UseG1GC a la variable de entorno JAVA_TOOL_OPTIONS.
• El coleccionista paralelo. Puede configurarlo explícitamente en la plantilla de AWS SAM agregando -XX: UseParallelGC a la variable de entorno JAVA_TOOL_OPTIONS.
• Shenandoah GC. Oracle JDK no lo proporciona, pero Amazon Corretto 21 JDK sí. Puede configurarlo explícitamente en la plantilla de AWS SAM agregando -XX: UseShenandoahGC a la variable de entorno JAVA_TOOL_OPTIONS.
• El recolector de basura Z. Hay dos algoritmos ZGC diferentes: el predeterminado y el más nuevo, unigeneracional. Puede configurarlo explícitamente en la plantilla de AWS SAM agregando -XX: UseZGC o -XX: UseZGC -XX: ZGenerational a la variable de entorno JAVA_TOOL_OPTIONS.

Medición de arranques fríos y cálidos con Java 21 utilizando diferentes algoritmos de recolección de basura

En nuestro experimento usaremos una aplicación ligeramente modificada introducida en la parte 9. Puede encontrar el código de la aplicación aquí. Básicamente, existen 2 funciones Lambda que responden a las solicitudes de API Gateway y recuperan el producto por identificación recibido de API Gateway desde DynamoDB. Una función Lambda GetProductByIdWithPureJava21LambdaWithGCAlg se puede usar con y sin SnapStart y la segunda GetProductByIdWithPureJava21LambdaAndPrimingWithGCAlg usa el cebado de invocación de solicitudes de SnapStart y DynamoDB.

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 con un experimento que duró aproximadamente 1 hora. 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. Realizamos experimentos dándole a las funciones Lambda 1024 MB de memoria y usando JAVA_TOOL_OPTIONS: "-XX: TieredCompilation -XX:TieredStopAtLevel=1" (compilación del cliente Java sin creación de perfiles), que tiene una muy buena compensación entre tiempos de inicio en frío y en caliente.

Desafortunadamente no pude hacer que la función Lambda se iniciara con The Z Garbage Collector (con el predeterminado y el generacional) y me encontré con el error:

Failed to commit memory (Operation not permitted)
[error][gc] Forced to lower max Java heap size from 872M(100%) to 0M(0%)
[error][gc] Failed to allocate initial Java heap (512M)
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

Probó una configuración de memoria más grande, como 1024 o 2048 MB, e incluso más MB, pero aún aparecía el mismo error.

Veamos los resultados de nuestras mediciones con otros 3 algoritmos de recolección de basura.

Abreviatura c es para arranque en frío y w es para arranque en caliente.

Hora de inicio en frío (c) y caliente (w) sin SnapStart habilitado en ms:

Hora de inicio en frío (c) y caliente (w) con SnapStart habilitado sin cebado en ms:

Hora de inicio en frío (c) y cálido (w) con SnapStart habilitado y con invocación de DynamoDB Priming en ms:

Conclusión

En este artículo exploramos el impacto de los algoritmos de recolección de basura de Java (G1, Parallel Collector y Shenandoah) en el rendimiento de la función Lambda con el tiempo de ejecución de Java 21. Vimos una gran diferencia entre el rendimiento de esos algoritmos. Usando la configuración predeterminada con G1 (la predeterminada), experimentamos (a veces con diferencia) los tiempos de arranque en frío y en caliente más bajos. Al utilizar SnapStart con la preparación de la solicitud de DynamoDB, los resultados de rendimiento son, como se esperaba, mucho más cercanos entre sí.

Consulte la documentación de cada algoritmo de recolección de basura para ajustar configuraciones como la mezcla y la memoria máxima, lo que puede proporcionar una mejora significativa en el rendimiento y realizar sus propias mediciones.