Hace unos días Pablo Asesor hacía una interesante pregunta en Facebook sobre el rendimiento de las Azure Functions, a lo cual Javier Estupiñan respondía desde su propia experiencia la prioridad en el modelo de pago que aplicaba según el rendimiento requerido; con la que no estuve del todo de acuerdo y propuse:
«De todas formas es muy sencillo de probar.
Se hace una función y se prueba su rendimiento en los tres formatos, sin que escale. Y luego escalando.
Lo intento este finde.»
Y aquí traigo las conclusiones…
Codificando y publicando las funciones
Lo que he realizado desde cero en más de tres horas – lo puedes ver en el canal de twitch – es una función que encuentra los números primos que existen entre los primeros cien mil números naturales; consumiendo un lapso de tiempo entre un segundo y medio, y más de seis para su completa ejecución.
En las pruebas con un millón de número, me encontré que a veces sobrepasaba el tiempo permitido por las funciones, y me daba un timeout. Pero de media, consumía unos tres minutos y medio.
Si te interesa ver el código, o si lo quieres probar tu mismo, lo tienes en el proyecto en GitHub.
A continuación construí desde el portal tres recursos de funciones, con las tres opciones de pago que nos permite Azure: consumo, premium y con un App Plan.
¿Cómo se cobran las Azure Functions por consumo?
Según la propia documentación de Azure, hay dos indicadores principales que se tienen en cuenta para facturar.
Lo primero es el número total de ejecuciones de la función cada més. Las cuales cada una es la respuesta a un evento, desencadenado por un enlace. Y que el primer millón de ejecuciones mensual es gratis.
Lo segundo es por el consumo de recursos, medidos en gigabytes por segundo, siendo esto es un poquito más complejo de calcular:
Se multiplica el tamaño medio de memoria RAM utilizada por la ejecución de la función, redondeando al alza a los 128Mb más cercanos, y llegando al Gb. y medio, por el tiempo de ejecución en intervalos de milisegundos.
Lo mínimo que se va a medir con una function por consumo son 128Mb en 100ms. Pero debo tener muy en cuenta que los primeros 400.000 Gb-seg son gratuitos.
Pero, ojito con esto, si en este caso estoy utilizando funciones con un trigger Http (llamadas Proxies Functions), el cálculo de milisegundos se realiza entre el response y el request (que puede durar segundos).
¿Premium, App Plan?
La versión Premium, utiliza el mismo sistema de facturación que las de pago por consumo, con cinco diferencias esenciales
- No tiene enfriamiento. Es decir, la función no se «apaga» nunca, y por ello está disponible de manera inmediata en cualquier momento aunque no haya sido lanzada en bastante tiempo.
- Tiene un rendimiento superior.
- Se puede conectar a redes virtuales.
- No tiene límite temporal de ejecución, aunque por defecto está configurado a 30 minutos.
- Es más caro.
Por último el App Plan, es igual que si fuera a montar un Web App o cualquier otro tipo de App Service, siendo la gran diferencia con las dos opciones anteriores el que su escalado está limitado al tamaño máximo establecido para el tipo de App Plan. Es decir, 10, 20 o 100 instancias si estoy utilizando un Plan del tipo Isolated con un Application Service Enviroment (ASE).
Si quieres investigar más a fondo lo puedes hacer en este artículo publicado en la documentación de Azure.
Resultados de las pruebas… el tamaño importa!
Una vez explicado todo lo anterior, llega el momento de la verdad y lanzo varias veces la misma función en los tres modos de coste, y en un número relativamente pequeño de repeticiones.
Y llegaron las sorpresas…!!
La opción de pago por cómputo y los AppPlan de tier Standar, tienen prácticamente el mismo rendimiento. Ya sea un S1 o un S3, la mejora en el rendimiento es muy pequeña.
El cambio es importante si utilizamos un AppPlan tipo Premium V2, el cual rebaja el tiempo a la mitad con respecto a las opciones anteriores, y gana un décima de segundo entre el más económico y el más potente con 840 ACU.
La reina, sin duda, es la function premium, que en todos los casos es la que mejor rendimiento consigue.
Además, y eso me preocupa bastante sobre la utilidad de la opción de pago por cómputo, es que los resultados no son consistentes ni confiables. Como se puede ver en la excel, llegue a obtener mediciones distintas en más de un 100%, lo cual habría que entender el porqué de variaciones tan grandes.
Conclusiones
Javier Estupiñan tenía razón, y el orden de rendimiento es cierto: Consumo, App Plan Standar, App Plan Premium V2, y Elastic Premium.
Pero, curiosamente yo también (aunque solo parcialmente). No es cuestión tanto de las ACU, que la mejora es pequeña o muy pequeña, si no lo que marca la diferencia es el tipo de SKU que escoja.
Y, además, hay más consideraciones que tengo que tener muy en cuenta: el modo de ejecución, el tiempo máximo, la estabilidad, el escalado y el enfriamiento.
Para finalizar, quiero hacer una segunda versión del código más completa y compleja, y que corra en un App Plan Isolated a ver si le gana a las EP1.
Una vez más, me fascina esta tecnología, y espero que este artículo sea de utilidad.