Solution de démarrage à froid Lambda?
Planifier une fonction lambda pour qu'elle soit appelée toutes les 20 minutes avec CloudWatch est le meilleur moyen de se débarrasser des heures de démarrage à froid lambda? (pas complètement se débarrasser de) ...
Est-ce que cela va coûter cher ou y a-t-il quelque chose qui me manque, car je l'ai mis en place actuellement et je pense que cela fonctionne.
Avant mon heure de démarrage à froid, elle durait environ 10 secondes et chaque appel suivant s'achevait en 80 ms. Désormais, chaque appel, quelle que soit sa fréquence, est d’environ 80 ms. Est-ce une bonne méthode jusqu'à ce que votre base d'utilisateurs s'agrandisse, puis vous pouvez désactiver cette option?
Ma deuxième option consiste simplement à utiliser Beanstalk et à avoir un serveur fonctionnant 24 heures sur 24, 7 jours sur 7, mais cela semble cher et je ne le préfère pas.
Autant que je sache, c’est le seul moyen de garder la fonction active en ce moment. Cela peut être coûteux uniquement lorsque vous avez beaucoup de ces fonctions.
Vous devez calculer vous-même combien payez-vous pour maintenir vos fonctions en vie, en tenant compte de leur nombre, de la durée de leur exécution à chaque fois et de la quantité de mémoire dont vous avez besoin.
Mais une fois toutes les 20 minutes équivaut à environ 2000 fois par mois, donc si vous utilisez par exemple 128 Mo et les faire terminer sous moins de 100 ms, alors vous pourriez garder bon nombre de ces fonctions en vie toutes les 20 minutes tout en restant sous le niveau gratuit - ce serait 20 secondes par mois et par fonction. Vous n'avez même pas besoin de l'éteindre après avoir reçu une charge plus importante, car ce ne sera plus pertinent à ce stade. En outre, vous ne pouvez jamais être sûr d'obtenir une charge uniforme tout le temps, donc vous pouvez garder votre code cardiaque en activité même dans ce cas.
Bien que je suppose que comme il est si peu coûteux de garder une fonction en vie (surtout si vous avez un argument spécial qui les fait revenir immédiatement) et que la différence est si grande (10 secondes contre 80 ms), pratiquement tout le monde le fera. il n'y a pratiquement aucune excuse pour ne pas. Dans ce cas, j’attends d’Amazon qu’il combatte cette pratique (en la rendant difficile ou plus onéreuse qu’elle ne l’est actuellement - ce qui ne serait pas judicieux) - ou en la rendant inutile dans l’avenir. Si la différence entre démarrage à chaud et démarrage à froid était de 100 ms, personne ne s'en inquiéterait. Si cela prend 10 secondes, tout le monde a besoin de contourner le problème.
Il devrait toujours y avoir une différence entre exécuter un code qui a été exécuté il y a une seconde et un code qui a été exécuté il y a un mois, car les avoir tous dans RAM et prêts à être utilisés gaspillerait beaucoup ressources, mais je ne vois aucune raison pour que cette différence ne soit pas moins perceptible ou même ne comporte que quelques étapes supplémentaires au lieu d’un démarrage à chaud et à froid.
Vous pouvez améliorer le temps de démarrage à froid en allouant plus de mémoire à votre fonction Lambda. Avec la valeur par défaut de 512 Mo, je vois des temps de démarrage à froid de 8 à 10 secondes pour les fonctions écrites en Java. Cela s’améliore à 2-3 secondes avec 1536 Mo de mémoire.
Amazon dit que c’est l’allocation de CPU qui compte vraiment, mais il n’ya aucun moyen de la changer directement. L'allocation de processeur augmente proportionnellement à la mémoire.
Et si vous souhaitez que les heures de démarrage à froid soient proches de zéro, il est préférable de garder la fonction au chaud, comme décrit ci-dessous.
Parmi les ajouts de mémoire pour lambda, il existe une autre approche pour réduire les démarrages à froid: utilisez l’outil Graal native-image. Le pot est traduit en code octet. Fondamentalement, nous ferions une partie du travail, qui est effectué sur des aws. Lorsque vous créez votre code, lors du chargement sur AWS, sélectionnez "Exécution personnalisée", et non Java8.
Article utile: https://engineering.opsgenie.com/run-native-Java-using-graalvm-in-aws-lambda-with-golang-ba86e27930bf
Il faut se méfier:
mais il a aussi ses limites; il ne supporte pas le chargement de classe dynamique, et le support de réflexion est également limité