definition en une ligne
Un démarrage à froid est le délai qui se produit lorsqu'une fonction ou un conteneur sans serveur démarre à partir de zéro pour traiter une requête, ajoutant ainsi de la latence au premier appel.
formule : Latence de démarrage à froid = Temps d'initialisation du runtime + Temps de chargement des dépendances + Temps d'exécution du gestionnaire. Généralement 100 ms-5 s en fonction du temps d'exécution et de la taille du bundle.
tl;dr
Les démarrages à froid sont la taxe cachée du sans serveur. Votre API peut répondre normalement en 80 ms, mais la première requête après une période d'inactivité atteint 2 secondes. Si cette première demande est la première expérience d'un utilisateur avec votre produit, vous venez de faire une très mauvaise première impression. Mesurez la latence de démarrage à froid séparément de la latence à chaud.
Définition simple
Lorsque vous déployez sur une plateforme sans serveur comme AWS Lambda, Vercel ou Cloudflare Workers, votre code ne s'exécute pas sur un serveur toujours actif. Au lieu de cela, la plate-forme lance une nouvelle instance lorsqu'une requête arrive. Si aucune instance n'est chaude (récemment utilisée), la plate-forme doit en démarrer une à froid : démarrez le runtime, chargez votre code et vos dépendances, initialisez votre gestionnaire. Ce coût de démarrage correspond au démarrage à froid et ajoute entre 50 ms et 5 secondes à la requête. Les requêtes suivantes réutilisent l’instance chaleureuse et sont rapides. Mais après une période d'inactivité (généralement 5 à 15 minutes), l'instance s'arrête et la requête suivante redémarre à froid.
Comment le calculer
Latence de démarrage à froid = initialisation de l'exécution + chargement des dépendances + exécution du gestionnaire (première exécution)
Mesurez-le en vérifiant la latence de votre première requête après une période d'inactivité par rapport à une requête chaleureuse :
- Déployez votre fonction, attendez 20 minutes, puis envoyez une requête. Notez la latence.
- Envoyez une autre demande immédiatement après. Notez la latence.
- La différence réside dans votre surcharge de démarrage à froid.
Suivez la fréquence des démarrages à froid dans votre surveillance. Si 30 % de vos requêtes sont des démarrages à froid, vous avez un problème d'architecture. S'il est inférieur à 5 %, les démarrages à froid ne constituent pas un goulot d'étranglement.
Exemple
Vous créez une API de traitement de webhook sur AWS Lambda avec Node.js. Temps de réponse à chaud : 45 ms. Après 15 minutes sans trafic (courant en dehors des heures d'ouverture), la requête suivante prend 1 200 ms. Votre offre fait 18 Mo car vous avez inclus l'intégralité du SDK AWS et une bibliothèque de génération PDF. Vous secouez l'arborescence du SDK (en important uniquement le client S3 au lieu du package complet) et chargez paresseusement la bibliothèque PDF uniquement pour les points de terminaison qui en ont besoin. Le bundle tombe à 3 Mo. Le démarrage à froid passe de 1 200 ms à 280 ms. Pour vos utilisateurs européens qui accèdent à l’API tôt le matin après une nuit d’inactivité, l’expérience passe de sensiblement lente à presque instantanée.
Lecture connexe
- Latence API
- [Délai de valorisation](/glossaire/délai de valorisation)
Termes associes
- Latence de l'API
- Délai de rentabilisation
- Taux d'activation
FAQ
Quelles plates-formes sans serveur connaissent les pires démarrages à froid ?+
Les environnements d'exécution AWS Lambda avec Java ou .NET peuvent atteindre 3 à 5 secondes. Node.js et Python sont plus rapides (100 à 500 ms). Vercel et Cloudflare Workers sont les plus rapides, souvent en moins de 50 ms, car ils utilisent des isolats V8 au lieu de conteneurs complets. Si les démarrages à froid sont importants pour votre produit, votre choix d'exécution et de plate-forme sont les principaux leviers.
Comment puis-je éviter les démarrages à froid sans payer pour des serveurs toujours actifs ?+
Gardez vos ensembles de fonctions petits (moins de 5 Mo). Utilisez des environnements d'exécution légers comme Node.js ou Go. Sur AWS Lambda, utilisez la concurrence provisionnée pour les points de terminaison critiques. Ou utilisez une tâche cron pour cingler vos fonctions toutes les 5 minutes pour les garder au chaud – un hack, mais cela fonctionne et ne coûte presque rien.