Comment ameliorer les temps de reponse de Laravel Vapor avec le prechauffage

Le prechauffage dans Laravel Vapor reduit les demarrages a froid, ce qui est essentiel pour les applications serverless. Lorsque vous deployez, aucun conteneur Lambda n'est chaud et pret a traiter les requetes par defaut. Cela entraine des demarrages a froid garantis qui peuvent ajouter jusqu'a 2 secondes aux temps de reponse. Le prechauffage envoie des requetes a un nombre specifie de conteneurs lors du deploiement et continue de les solliciter toutes les 5 minutes pour les garder chauds.

Combien de prechauffage avez-vous besoin ?

Considerez un droplet DigitalOcean a 5 $/mois avec 1 Go de memoire. Si chaque requete Laravel utilise environ 25 Mo, le droplet peut theoriquement gerer environ 40 requetes simultanees (en supposant que toute la memoire est allouee a PHP).

Pour atteindre cette concurrence dans Vapor, vous auriez besoin de 40 conteneurs Lambda chauds. La bonne nouvelle : ce n'est pas cher.

Comparaison des couts

Tarification AWS Lambda dans US East (N. Virginia) :

• Cout de duree : 0,0000166667 $ par Go-seconde
• Cout par requete : 0,20 $ par million de requetes

Pour une fonction Lambda avec 1024 Mo de memoire :

• Un ping de prechauffage s'execute environ toutes les 5 minutes
• 40 conteneurs x 12 pings/heure x 24 heures = 11 520 requetes par jour
• Mensuel : environ 345 600 requetes
• Cout des requetes : environ 0,07 $/mois
• Cout de duree (en supposant 100 ms par ping) : environ 0,06 $/mois

Cout total du prechauffage pour 40 conteneurs : environ 0,13 $/mois -- considerablement moins cher que le VPS le plus basique.

Configurer le prechauffage dans Vapor

Dans votre configuration vapor.yml, definissez la valeur warm pour chaque environnement :

environments:
  production:
    warm: 40

Cela indique a Vapor de maintenir 40 conteneurs chauds en permanence.

Quand augmenter le prechauffage

Surveillez les schemas de concurrence de votre application. Si vous remarquez des demarrages a froid pendant les periodes de fort trafic, augmentez le nombre de conteneurs chauds. Les declencheurs courants incluent :

• Les campagnes marketing qui generent des pics de trafic soudains
• Les envois d'emails en masse qui dirigent de nombreux utilisateurs vers votre site simultanement
• Les schemas de trafic lies aux fuseaux horaires ou les heures de pointe necessitent plus de capacite

Prechauffage vs. Concurrence provisionnee

AWS propose egalement la Concurrence provisionnee comme alternative au prechauffage. Celle-ci maintient les fonctions Lambda initialisees et pretes a repondre en quelques dizaines de millisecondes. Cependant, la Concurrence provisionnee est significativement plus couteuse que l'approche de prechauffage de Vapor et n'est generalement necessaire que pour les applications critiques en latence ou meme des demarrages a froid occasionnels sont inacceptables.

Bonnes pratiques

1. Prechauffez toujours les environnements de production. Il n'y a aucune bonne raison de ne pas prechauffer etant donne le cout negligeable.
2. Definissez les valeurs de prechauffage en fonction de l'utilisation concurrente typique, pas du trafic de pointe. L'autoscaling gere le trafic en rafale ; le prechauffage gere la charge de base.
3. Surveillez les taux de demarrage a froid via les metriques CloudWatch pour affiner votre nombre de conteneurs chauds au fil du temps.
4. Envisagez des deploiements separes pour differentes charges de travail (requetes web vs. workers de file d'attente) avec des configurations de prechauffage independantes.

Le prechauffage est l'une des optimisations les plus simples et les moins couteuses que vous puissiez faire pour une application Laravel serverless. Pour quelques centimes par mois, vous eliminez la plainte la plus courante concernant les architectures serverless : la latence de demarrage a froid.