Solución:
Hasta donde yo sé, esta es la única forma de mantener activa la función en este momento. Puede resultar caro solo cuando tiene muchas de esas funciones.
Tendría que calcular usted mismo cuánto paga por mantener vivas sus funciones considerando cuántas de ellas tiene, cuánto tiempo lleva ejecutarlas cada vez y cuánta memoria necesita.
Pero una vez cada 20 minutos es algo así como 2000 veces al mes, por lo que si usa, por ejemplo, 128 MB y hace que finalicen en menos de 100 ms, entonces podría mantener activas muchas de estas funciones a intervalos de 20 minutos y aún estar en el nivel gratuito, sería 20 segundos al mes por función. Ni siquiera necesita apagarlo después de obtener una carga más grande porque será irrelevante en este punto. Además, nunca puede estar seguro de obtener una carga uniforme todo el tiempo, por lo que puede mantener activo el código de los latidos del corazón incluso en ese momento.
Aunque supongo que, dado que es tan barato mantener viva una función (especialmente si tiene un argumento especial que los hace regresar de inmediato) y que la diferencia es tan grande (10 segundos frente a 80 ms), casi todos lo harán. eso – prácticamente no hay excusa para no hacerlo. En ese caso, espero que Amazon luche contra esa práctica (haciéndola más difícil o más cara de lo que es actualmente, lo que no sería una medida inteligente) o que no la necesite en el futuro. Si la diferencia entre el arranque en caliente y en frío fuera de 100 ms, nadie se molestaría. Si son 10 segundos, entonces todos deben solucionarlo.
Siempre tendría que haber una diferencia entre ejecutar un código que se ejecutó hace un segundo y un código que se ejecutó hace un mes, porque tenerlos todos en la RAM y listos para funcionar desperdiciaría muchos recursos, pero no veo razón por la cual esa diferencia no podría hacerse menos notoria o incluso tener algunos pasos más en lugar de solo arranque en caliente y en frío.
Puede mejorar el tiempo de inicio en frío asignando más memoria a su función Lambda. Con los 512 MB predeterminados, veo tiempos de inicio en frío de 8 a 10 segundos para las funciones escritas en Java. Esto mejora a 2-3 segundos con 1536 MB de memoria.
Amazon dice que lo que realmente importa es la asignación de CPU, pero no hay forma de cambiarla directamente. La asignación de CPU aumenta proporcionalmente a la memoria.
Y si desea tiempos de arranque en frío cercanos a cero, mantener la función caliente es el camino a seguir, como se sugiere en rsp.
A partir de diciembre de 2019, AWS Lambda admite la simultaneidad reservada (por lo que puede establecer la cantidad de funciones lambda que estarán listas y esperando nuevas llamadas) [1]
La desventaja de esto es que se le cobrará por la concurrencia reservada. Si aprovisiona una simultaneidad de 1, para una lambda con 128 MB activo las 24 horas durante todo el mes, se le cobrará: 1 instancia x 30 días x 24 horas x 60 minutos x 60 segundos x (128/1024) = 324.000 GB-seg. (casi toda la capacidad que ofrece AWS para el nivel sin lambda) [2]
Desde arriba, obtendrá una instancia lambda que responde muy rápido … sin embargo, las llamadas simultáneas posteriores pueden sufrir un “arranque en frío”.
Además, puede configurar el ajuste de escala automático de la aplicación para administrar dinámicamente la simultaneidad aprovisionada de su lambda. [3]
Refs:
- https://aws.amazon.com/blogs/aws/new-provisioned-concurrency-for-lambda-functions/
- https://aws.amazon.com/lambda/pricing/
- https://docs.aws.amazon.com/lambda/latest/dg/configuration-concurrency.html