En este artículo, vamos a comparar el rendimiento de una función AWS Lambda programada con Quarkus 1.7.1 y que realiza inserciones en una tabla que se creó sobre una base de datos RDS Aurora PostgreSQL. Si quieres saber cómo programar un Lambda con Quarkus puedes referirte a este artículo previo. También podrás observar este video como un episodio en mi canal de YouTube.

Para esta prueba vamos a tener las siguientes premisas:

  • El código de la función será el mismo a lo largo de ambas pruebas.
  • En el primer Lambda tendremos el código en modo JVM usando el runtime de Java 11.
  • La segunda Lambda tendremos nuestro código en modo nativo.
  • Para la prueba usaremos el AWS Lambda Power Tuning de Alex Casalboni y que podemos ver aquí.
  • La prueba hace 300 iteraciones para cada caso.
  • La instancia de RDS que se aprovisiona es lo suficiente robusta para garantizar que no influye en las pruebas.
  • Ambas Lambdas operan en modo VPC.

Modo JVM

El resultado de la ejecución de nuestra función en modo JVM es el siguiente:

JVM

Podemos notar varias cosas:

  • Mejor Tiempo. De acuerdo a la prueba, el mejor tiempo se obtuvo al tener una configuración de 512 MB con una respuesta de 8 ms.
  • Peor Tiempo. El peor tiempo se obtuvo al usar 1536 MB asignados, para 19 ms.
  • Mejor Costo. La mejor relación rendimiento/costo se obtiene al configurar el lambda con 512 MB (8 ms a $0.000000833)
  • Notas. Nuestro lambda no pudo funcionar con 256 MB o 128 MB.

Modo Nativo

El resultado de la ejecución de nuestra función en modo nativo es el siguiente:

Native

Y acá podemos desprender lo siguiente:

  • Mejor Tiempo. De acuerdo a la prueba, el mejor tiempo se obtuvo al tener una configuración de 1024 MB con una respuesta de 6 ms.
  • Peor Tiempo. El peor tiempo se obtuvo al usar 512 MB asignados, para 8 ms.
  • Mejor Costo. La mejor relación rendimiento/costo se obtiene al configurar el lambda con 128 MB (7 ms a $0.000000208).
  • Notas. Nuestro lambda en modo nativo pudo ejecutarse en todas las combinaciones de RAM.

Desplegar el Lambda en modo nativo es crucial

Los números hablan por si mismos. No sólo nuestros Lambda es más rápido en modo nativo (7 ms contra 8 ms); sino que lo hace en una configuración de RAM 4 veces más pequeña y por tanto 4 veces más económica. Para aquellos que no estén al tanto, AWS Lambda cobra cada ejecución con base a su duración en múltiplos de 100 ms y el RAM asignado.

Pero veamos algo importante a nivel general, nuestro peor tiempo fue 19 ms! y eso no está nada mal.

AWS RDS Proxy

Luego de esta pruebas me cuestione si el tiempo de abrir una conexión a la base de datos podría ser un factor que estuviera influyendo. Así que decidí repetir las pruebas usando RDS Proxy.

Amazon RDS Proxy, como nos dice el sitio de AWS, nos brinda un pool de conexiones hacia la base de datos, mejorando la eficiencia y escalabilidad de las aplicaciones; además de otras funciones interesantes tales como una mejora sustancial en los tiempos de respuesta ante un failover. Y lo mejor, a nivel de código únicamente cambiamos el URL hacia la base de datos.

Así que vayamos a los resultados.

Modo JVM

El resultado de la ejecución de nuestra función en modo JVM es el siguiente:

JVM

Podemos notar varias cosas:

  • Mejor Tiempo. De acuerdo a la prueba, el mejor tiempo se obtuvo al tener una configuración de 2048 MB con una respuesta de 14 ms.
  • Peor Tiempo. El peor tiempo se obtuvo al usar 512 MB asignados, para 22 ms.
  • Mejor Costo. La mejor relación rendimiento/costo se obtiene al configurar el lambda con 512 MB (22 ms a $0.000000833)

Modo Nativo

El resultado de la ejecución de nuestra función en modo nativo es el siguiente:

Native

Y tenemos:

  • Mejor Tiempo. De acuerdo a la prueba, el mejor tiempo se obtuvo al tener una configuración de 2048 MB con una respuesta de 10 ms.
  • Peor Tiempo. El peor tiempo se obtuvo al usar 1536 MB asignados, para 14 ms.
  • Mejor Costo. La mejor relación rendimiento/costo se obtiene al configurar el Lambda con 128 MB (12 ms a $0.000000208).

Los resultados en los tiempos me sorprendieron, sé que Proxy no promete mejores tiempos, está diseñado para otras cosas: como la recuperación más pronta ante un failover. Pero podemos resumir que, en mi ejercicio, usar RDS Proxy significó un aumento en los tiempos de respuesta de más de 2 veces en promedio.

Conclusión

Espero que este artículo les haya sido de utilidad y vean el beneficio que nos da desplegar nuestras funciones Lambda con Quarkus en modo nativo.