Le modèle asynchrone
Boucle d'événements, promesses, et tout ce qui fige un serveur Node.
Le modèle asynchrone
Un endpoint qui répondait en 30 millisecondes se met à répondre en 4 secondes, mais seulement quand un autre endpoint est sollicité. Les deux n'ont aucun code en commun, pas de base de données partagée, pas de verrou. Les traces d'exécution montrent un temps de traitement normal côté application ; c'est le temps entre l'arrivée du paquet et le début du traitement qui explose. Aucun outil de profilage classique ne montre le coupable, parce que le coupable n'est pas dans le chemin observé.
Ce scénario est la signature d'une boucle d'événements bloquée, et c'est le mode de panne le plus fréquent et le plus déroutant de Node. Un seul appel synchrone coûteux — une lecture de fichier avec readFileSync, un JSON.parse sur trois mégaoctets, une expression régulière catastrophique, un hachage bcrypt avec un facteur de coût élevé — suffit à mettre en attente toutes les autres requêtes du processus. Cette leçon vous donne le modèle mental exact de ce qui se passe, puis les outils pour le mesurer et le corriger.
Pile, file de messages, boucle
Node exécute votre JavaScript sur une pile d'appels unique. Quand la pile se vide, la boucle d'événements regarde ce qui est prêt et empile la prochaine unité de travail. Cette boucle n'est pas une file unique : elle parcourt des phases successives, en boucle, tant qu'il reste du travail.
Commentaires
Les commentaires sont alimentés par GitHub Discussions
Connectez-vous avec GitHub pour participer à la discussion