Calcul de charge Nginx
Estimez rapidement la capacité de votre serveur Nginx à partir des paramètres clés de concurrence, de latence et de marge de sécurité. Ce simulateur s’appuie sur une logique de capacité proche de la loi de Little pour transformer vos connexions utilisables en requêtes par seconde soutenables.
Remplissez les paramètres puis cliquez sur le bouton pour obtenir une estimation de capacité.
Guide expert du calcul de charge Nginx
Le calcul de charge Nginx consiste à traduire un volume de trafic attendu en contraintes concrètes sur les processus, les connexions, le temps de réponse et les ressources système. Beaucoup d’équipes ne regardent que le nombre de requêtes par seconde, alors qu’en pratique la stabilité d’un frontal Nginx dépend d’un équilibre plus subtil entre concurrence réelle, latence moyenne, pics de trafic, keepalive, surcharge TLS, capacité réseau et comportement de l’application située derrière le reverse proxy. Un calcul de charge sérieux sert à éviter deux erreurs opposées : sous-dimensionner l’infrastructure et provoquer de la saturation, ou sur-dimensionner et payer inutilement de la capacité inactive.
Dans Nginx, la capacité théorique la plus souvent utilisée démarre avec la formule worker_processes × worker_connections. Elle donne une borne haute de connexions ouvertes, pas un volume garanti de requêtes utiles. Cette nuance est essentielle. Une connexion keepalive occupée mais inactive consomme une place dans le budget de sockets. Une requête API lente immobilise une file de traitement plus longtemps qu’une réponse statique de 10 ms. C’est pour cela qu’un calcul de charge crédible doit ensuite corriger la capacité théorique par la latence, la marge de sécurité, le mode de trafic et l’empreinte CPU du chiffrement.
La formule de base : connexions, concurrence et loi de Little
Une méthode pratique consiste à combiner la capacité de connexions avec la loi de Little. Cette loi dit que la concurrence moyenne est égale au débit multiplié par le temps moyen passé dans le système. En notation simple :
- Concurrence = RPS × temps de réponse en secondes
- RPS soutenable = connexions réellement disponibles ÷ temps de réponse
Supposons une configuration avec 4 worker_processes et 1024 worker_connections. La borne brute est de 4096 connexions. Si 25 % sont tenues par du keepalive inactif, il reste 3072 connexions potentiellement utiles. Si vous gardez 20 % de marge de sécurité pour absorber les pics, le budget descend à 2457. Si le temps de réponse moyen reste à 120 ms, soit 0,12 s, alors la capacité approximative devient 2457 ÷ 0,12 = 20 475 requêtes par seconde avant autres pénalités. En présence de TLS, d’un profil API dynamique et d’un backend imparfait, ce chiffre doit encore être réduit. Voilà pourquoi les calculateurs de charge sérieux appliquent des coefficients correctifs.
Pourquoi la capacité théorique est souvent trompeuse
Sur le papier, Nginx est extrêmement performant. Dans la réalité, la charge utile dépend de nombreux facteurs exogènes :
- les limites du noyau comme ulimit -n et le nombre maximal de fichiers ouverts ;
- les délais amont vers PHP-FPM, Node.js, Gunicorn ou un cluster applicatif ;
- la compression gzip ou brotli, qui augmente le coût CPU ;
- le chiffrement TLS et la qualité des suites cryptographiques ;
- le type de trafic, par exemple les longues connexions WebSocket ;
- les pics d’audience irréguliers, très différents d’une moyenne journalière ;
- la taille des réponses et la capacité du réseau à sortir les octets nécessaires.
Les paramètres Nginx à intégrer dans un calcul de charge
1. worker_processes
En environnement moderne, la valeur auto est souvent pertinente car elle s’aligne sur le nombre de cœurs disponibles. Toutefois, si le serveur réalise d’autres tâches intensives, vous pouvez décider de ne pas allouer 100 % des cœurs à Nginx. Le bon calcul ne consiste donc pas seulement à faire correspondre un chiffre au CPU, mais à vérifier le budget CPU global de l’hôte.
2. worker_connections
Cette directive détermine combien de connexions un worker peut gérer simultanément. Le produit avec worker_processes donne un plafond. Mais ce plafond n’est valable que si le système autorise suffisamment de descripteurs de fichiers et si le pattern d’usage ne crée pas de goulets ailleurs. Monter worker_connections sans ajuster l’OS est une erreur classique.
3. Temps de réponse moyen et temps de réponse en pointe
Le temps de réponse influe directement sur la concurrence. Si votre backend passe de 100 ms à 400 ms lors d’une montée en charge, la capacité RPS chute mécaniquement d’un facteur proche de 4 à budget de connexions constant. Le calcul de charge doit donc toujours considérer non seulement la moyenne, mais aussi le P95 et le P99.
4. Keepalive
Le keepalive améliore souvent les performances réseau et réduit les handshakes, mais il réserve aussi des connexions. Dans un site très visité avec beaucoup d’utilisateurs intermittents, la proportion de connexions inactives peut devenir significative. Il faut donc modéliser un pourcentage de budget perdu à cause des connexions en attente.
5. TLS et chiffrement
Le coût CPU du TLS varie selon le matériel, la version du protocole, le support AES-NI, la reprise de session et la volumétrie. Sur une machine moderne, la surcharge peut rester modérée. Sur une infrastructure peu optimisée, le coût peut rogner sensiblement la capacité utile. Le calculateur ci-dessus applique un coefficient simple afin de représenter cet effet.
Tableau de repères pratiques pour interpréter la charge
| Niveau d’utilisation estimé | Lecture opérationnelle | Comportement observé fréquent | Action recommandée |
|---|---|---|---|
| 0 % à 50 % | Zone confortable | Latence stable, marge pour les pics, faible pression sur les files | Surveiller les tendances, pas d’urgence |
| 50 % à 75 % | Charge saine mais à suivre | Hausse mesurée du CPU et des connexions, incidents rares | Tester les pics et vérifier les timeouts amont |
| 75 % à 90 % | Zone de vigilance | P95 qui dérive, sensibilité accrue aux pics et aux défaillances backend | Optimiser cache, compression, upstreams et files descriptors |
| 90 % à 100 % | Pré-saturation | Risque élevé de files d’attente, 499, 502, 504 et dégradation en cascade | Ajouter de la capacité ou réduire la latence rapidement |
| Plus de 100 % | Surcharge probable | Rejets, timeouts, queueing important, expérience utilisateur fortement dégradée | Scale out immédiat, tuning d’urgence, limitation de trafic si nécessaire |
Exemple chiffré : l’impact réel du temps de réponse
Les statistiques suivantes illustrent un phénomène mesuré constamment en production : à concurrence utile constante, chaque augmentation du temps de réponse réduit la capacité RPS. Le tableau ci-dessous repose sur un budget de 2 000 connexions réellement disponibles après correction keepalive et marge de sécurité. Les chiffres sont purement arithmétiques, mais ils représentent bien un comportement réel des systèmes HTTP.
| Temps de réponse moyen | Concurrence utile disponible | Capacité maximale estimée | Baisse de capacité vs 100 ms |
|---|---|---|---|
| 100 ms | 2 000 | 20 000 RPS | 0 % |
| 150 ms | 2 000 | 13 333 RPS | 33,3 % |
| 250 ms | 2 000 | 8 000 RPS | 60 % |
| 500 ms | 2 000 | 4 000 RPS | 80 % |
| 1 000 ms | 2 000 | 2 000 RPS | 90 % |
Comment réaliser un calcul de charge Nginx fiable
- Mesurez votre trafic actuel : moyenne, pics, P95, P99, taille moyenne des réponses, distribution par endpoints.
- Déterminez la concurrence utile : ne partez pas du plafond brut, retranchez keepalive, marge d’exploitation et overhead.
- Projetez le temps de réponse en charge : le backend ralentit souvent avant Nginx.
- Intégrez la nature du trafic : API, statique, streaming, WebSocket, téléchargements lourds.
- Validez par test de charge : un calcul n’est qu’un modèle jusqu’à confrontation au réel.
- Surveillez les métriques système : CPU, mémoire, open files, SYN backlog, retransmissions, saturation disque et réseau.
Les métriques les plus utiles pendant un test
Pour vérifier la justesse de votre calcul, corrélez systématiquement les courbes suivantes : RPS, latence moyenne, P95, P99, erreurs HTTP, usage CPU, file descriptors ouverts, connexions actives et temps de réponse amont. Une hausse simultanée de la latence et des erreurs côté upstream montre généralement que le problème n’est pas Nginx lui-même, mais le service derrière lui.
Erreurs fréquentes dans l’estimation de charge
- Confondre connexions et requêtes : une connexion n’est pas forcément une requête active.
- Ignorer les limites OS : des worker_connections élevés ne servent à rien si le système bloque avant.
- Négliger le backend : Nginx peut rester sain pendant que PHP-FPM ou l’API se noie.
- Utiliser seulement la moyenne : les incidents naissent souvent sur les percentiles élevés.
- Oublier la bande passante : des réponses volumineuses peuvent saturer le réseau avant la couche HTTP.
- Appliquer zéro marge : une plateforme sans réserve s’effondre au premier pic ou incident partiel.
Optimisations qui améliorent directement votre capacité utile
Réduire la latence amont
C’est souvent le levier le plus puissant. Comme la capacité RPS est inversement proportionnelle au temps de réponse, gagner 50 ou 100 ms sur un endpoint fréquent peut augmenter fortement la charge absorbable. Caching applicatif, index SQL, pooling de connexions et réduction des appels réseau internes produisent des gains immédiats.
Exploiter intelligemment le cache Nginx
Si une partie des réponses peut être servie depuis le cache, Nginx cesse de dépendre aussi fortement du backend pour ces requêtes. Le taux de cache hit est donc une variable de premier plan dans le calcul de charge. Un gain de 20 à 40 points de cache hit peut transformer radicalement la stabilité sous pointe.
Réviser keepalive et timeouts
Des timeouts trop longs immobilisent inutilement des connexions. Des réglages trop agressifs dégradent en revanche l’expérience client. Le bon niveau est celui qui préserve les bénéfices du keepalive sans laisser grossir un stock de sockets inactives trop coûteux.
Dimensionnement et résilience : penser au-delà d’un seul serveur
Le calcul de charge Nginx ne doit pas s’arrêter au nœud unitaire. En production, il faut raisonner en architecture. La capacité totale de la plateforme dépend du nombre d’instances, de l’équilibrage, des zones de disponibilité, du comportement lors des déploiements et de la perte possible d’un nœud. Une bonne pratique consiste à vérifier que la plateforme reste sous un seuil d’utilisation acceptable même après la perte d’une instance. Autrement dit, si vous avez quatre nœuds, demandez-vous si trois nœuds seulement peuvent supporter le trafic de pointe avec une marge de sécurité suffisante.
Cette logique rejoint les principes généraux de l’ingénierie de performance et de résilience recommandés par des sources institutionnelles et académiques. Pour approfondir la modélisation de performance, consultez les ressources du Carnegie Mellon University. Pour la gouvernance du risque et la résilience opérationnelle, les publications du NIST sont utiles. Enfin, pour la préparation face aux pics malveillants et aux attaques volumétriques, la CISA fournit des guides pratiques orientés défense.
Conclusion
Un bon calcul de charge Nginx n’est ni un simple produit de paramètres, ni un chiffre figé. C’est un modèle vivant qui relie configuration, comportement réseau, latence applicative et objectifs de service. Commencez par la capacité théorique de connexions, corrigez-la avec keepalive, marge de sécurité, TLS et profil de trafic, puis transformez cette concurrence utile en RPS grâce au temps de réponse observé. Ensuite, validez toujours par des tests de charge progressifs et par l’observation des métriques réelles. C’est cette discipline qui permet de passer d’une configuration plausible à une plateforme réellement fiable.