5.2Performance, clustering & mise à l'échelle
L'essentiel en 30 secondes
- Mono-thread : un processus Node n'utilise qu'un cœur — le clustering (module cluster ou PM2) lance une instance par cœur.
- Cache d'abord : mettre en cache les résultats coûteux (mémoire ou Redis) — souvent le levier le plus impactant.
- Mesurer avant d'optimiser : profiler pour trouver les vrais goulots — jamais d'optimisation prématurée.
Mini-cas filé — Salim encaisse la charge à Alger
L'API typée de Salim à Alger commence à ramer : la page d'accueil de la boutique met du temps à répondre aux heures de pointe. Plutôt que de tout réécrire, il mesure : les requêtes de catalogue reviennent sans cesse et la base est sollicitée pour rien. Il active le clustering pour exploiter les cœurs du serveur et met en cache le catalogue. Suite du cas 5.1 — Salim optimise ce qu'il a mesuré, pas au hasard.
Suite du cas 5.1 — Salim applique la règle d'or : mesurer d'abord, optimiser ensuite.
1. Clustering et worker threads
Node est mono-thread : un processus n'utilise qu'un cœur, alors que les serveurs en ont plusieurs. Le clustering (module natif cluster ou PM2) lance plusieurs instances de l'application (une par cœur) qui se répartissent les requêtes — exploitant tous les cœurs. PM2 ajoute le redémarrage automatique, le monitoring et les logs. Les worker threads, eux, exécutent les tâches CPU-intensives (calculs lourds qui bloqueraient la boucle d'événements) sur des threads séparés. Salim lance son API en mode cluster : la capacité est multipliée sans changer une ligne de logique.
Réflexe : si un seul processus tourne sur une machine multi-cœurs, des ressources dorment — le clustering est la mise à l'échelle verticale standard de Node.
2. Les leviers qui paient
Autres leviers : la mise en cache (mémoire ou Redis — stocker les résultats coûteux pour ne pas les refaire, souvent le plus impactant), l'optimisation des requêtes de base (indexation, éviter le problème N+1 — la base est très souvent le vrai goulot), ne pas bloquer la boucle d'événements (pas d'opérations synchrones lourdes sur le thread principal), le parallélisme (Promise.all pour les opérations indépendantes), et le scaling horizontal (plusieurs instances derrière un load balancer — d'où l'intérêt des applications stateless et des JWT). Salim met le catalogue en cache : les requêtes répétées ne touchent plus la base.
Ordre de rentabilité typique : base de données (index, N+1), cache, clustering, puis scaling horizontal — toujours guidé par la mesure.
3. La bonne démarche : mesurer, cibler, vérifier
Principe essentiel : ne pas optimiser prématurément. Écrire du code correct et clair d'abord, mesurer (profiler, métriques, temps de requêtes) pour identifier les vrais goulots quand ils surviennent, optimiser ciblé là où ça compte, puis re-mesurer pour confirmer. Optimiser à l'aveugle fait perdre du temps, complexifie le code et rate presque toujours le vrai problème — l'intuition trompe, la mesure tranche. Salim profile avant de toucher au code : le goulot était la base, pas ses boucles.
Node excelle pour l'I/O (serveurs, API, temps réel) — la limite mono-thread concerne le CPU, pas l'I/O, et la plupart des applications web sont limitées par l'I/O. Bien utilisé, Node sert de très grandes charges.
🔎 Exemple concret — Salim exploite les cœurs
Clustering avec PM2, cache ensuite.
# lancer une instance par cœur
pm2 start app.js -i max
# mesurer AVANT d'optimiser (profilage)
# mettre en cache un résultat coûteux (Redis)
# vérifier : rien ne bloque la boucle d'événementsLecture : chaque ligne est une étape testable séparément.
Leçon : la base de données est souvent le vrai goulot — la mesurer en premier.
Vocabulaire de la section
- Clustering
- Plusieurs instances de l'app (une par cœur) qui se répartissent les requêtes.
Exemple simple : Salim lance son API avec PM2 en mode cluster.
Ce que ce n'est pas : un Node qui utiliserait tous les cœurs automatiquement.
Réflexe : combien de cœurs dorment sur mon serveur ?
- Worker threads
- Threads séparés pour les calculs lourds, sans bloquer la boucle.
Exemple simple : Salim y délègue un export volumineux qui figeait l'API.
Ce que ce n'est pas : le clustering lui-même.
Réflexe : ce calcul bloque-t-il le thread principal ?
- Mise en cache
- Stocker les résultats coûteux pour ne pas les recalculer.
Exemple simple : Le catalogue de Salim servi depuis le cache, plus depuis la base.
Ce que ce n'est pas : ajouter des serveurs avant de cacher.
Réflexe : quelles requêtes reviennent sans cesse à l'identique ?
- Profilage
- Mesurer pour identifier les vrais goulots avant d'optimiser.
Exemple simple : Salim découvre que la lenteur vient d'une requête non indexée.
Ce que ce n'est pas : optimiser ses boucles à l'intuition.
Réflexe : ai-je mesuré avant de toucher au code ?
- Scaling horizontal
- Plusieurs serveurs derrière un répartiteur de charge.
Exemple simple : Salim prévoit des instances réplicables grâce à son app stateless.
Ce que ce n'est pas : exploiter les cœurs d'une seule machine.
Réflexe : mon app se réplique-t-elle facilement (stateless) ?
En pratique — Optimiser et mettre à l'échelle une application
- Utilisez le clustering (module cluster ou PM2) pour lancer une instance par cœur et exploiter tout le processeur (Node étant mono-thread).
- Mettez en cache un résultat coûteux (requête fréquente) — en mémoire ou avec Redis — et mesurez le gain.
- Profilez pour identifier les vrais goulots d'étranglement AVANT d'optimiser (mesurer avant d'optimiser) ; vérifiez que rien ne bloque la boucle d'événements.
- Comprenez le scaling horizontal : plusieurs instances derrière un load balancer, et l'intérêt d'une application « stateless » (JWT) pour se répliquer facilement.
Script prêt à dire — justifier une optimisation
« À Alger, notre API ralentit aux heures de pointe. J'ai mesuré : ce sont les requêtes catalogue qui saturent la base. Je propose deux gestes ciblés : clustering pour exploiter tous les cœurs, et cache sur le catalogue. On re-mesure après, et on n'ajoute des serveurs que si la mesure le justifie. »
À dire au responsable pour faire valider une optimisation mesurée plutôt qu'une réécriture à l'aveugle.
Modèle copier-coller — fiche diagnostic perf
PERF — DIAGNOSTIC
SYMPTOME : _______________ (quand ? ___)
MESURE : temps de réponse ___ · requête la plus lente ___
GOULOT SUSPECTE : base / cache absent / boucle bloquée / CPU : ___
ACTION CIBLEE : clustering / cache / index / worker : ___
RE-MESURE : avant ___ → après ___ · GAIN : ___Solo / petit budget
Salim seul : PM2 en mode cluster + cache en mémoire suffit pour encaisser les pointes sans nouveau serveur.
TPE / équipe réduite
Indexer les requêtes lentes d'abord : souvent le gain le plus rapide, sans infrastructure.
PME à Alger
Salim planifie les mesures aux heures de pointe à Alger, avec un protocole de re-mesure après chaque changement.
Équipe qui démarre
Binôme : l'un profile pendant que l'autre prépare le cache ; revue commune des mesures avant toute optimisation.
✓ Bonnes pratiques
- Exploiter tous les cœurs avec le clustering (PM2 en production).
- Mettre en cache les résultats coûteux ; optimiser les requêtes de base (index, N+1).
- Mesurer (profiler) avant d'optimiser, et cibler les vrais goulots.
✗ Pièges fréquents
- Laisser un seul processus n'exploiter qu'un cœur.
- Optimiser prématurément (perte de temps, complexité inutile).
- Bloquer la boucle d'événements avec un calcul CPU lourd sur le thread principal.
Points clés à retenir
- Node étant MONO-THREAD : le CLUSTERING (cluster / PM2) lance une instance par cœur pour exploiter TOUS les cœurs. WORKER THREADS pour le CPU lourd.
- Leviers : MISE EN CACHE (Redis — souvent le plus impactant), optimisation des REQUÊTES (indexation, éviter le N+1), ne pas BLOQUER la boucle, parallélisme (Promise.all).
- MESURER (profiler) avant d'optimiser (règle d'or) ; identifier les vrais goulots plutôt qu'optimiser à l'aveugle.
- SCALING HORIZONTAL : plusieurs serveurs derrière un LOAD BALANCER (favorise les apps stateless/JWT). NE PAS optimiser prématurément.
Défi 48h — appliquez demain
Remplissez la fiche diagnostic pour 1 lenteur réelle de votre app : symptôme, mesure, goulot suspecté — sans encore toucher au code.
- Je peux expliquer clustering vs worker threads en une phrase.
- Ma fiche diagnostic (mesure avant optimisation) est remplie.
- Je sais pourquoi la base est le premier suspect.
Questions fréquentes
Pourquoi le clustering est-il nécessaire, et Node est-il un mauvais choix pour la performance ?
Le clustering est nécessaire car Node exécute votre code sur un seul thread (un cœur), alors que les serveurs modernes en ont plusieurs : un seul processus gaspille les autres cœurs. Le clustering (module cluster, ou PM2 qui l'automatise avec redémarrage auto et monitoring) lance plusieurs processus qui se répartissent les requêtes. Mais cela ne fait pas de Node un mauvais choix : Node excelle pour l'I/O (serveurs, API, temps réel — la majorité des apps web) avec son modèle non-bloquant, la limite mono-thread concerne le CPU (gérable via worker threads), et Node scale bien (vertical + horizontal). Bien utilisé, Node sert de très grandes charges.
Comment savoir QUAND et QUOI optimiser sans tomber dans l'optimisation prématurée ?
Règle d'or : n'optimisez pas avant un problème réel et mesuré. L'optimisation prématurée fait perdre du temps, complexifie le code et rate le vrai goulot (l'intuition trompe). La démarche : code correct et clair d'abord, mesurer (profilage, métriques) quand un problème survient, optimiser ciblé là où ça compte, re-mesurer pour confirmer. Leviers courants : base de données (index, N+1), cache (Redis), clustering, boucle non bloquée, parallélisme, scaling horizontal.
Comment une application Node exploite-t-elle tous les cœurs d'un serveur ?