Comment optimiser la configuration de votre serveur web (Apache / Nginx) pour le trafic de masse ?
Optimiser un serveur web pour absorber un trafic de masse ne consiste pas seulement à lui ajouter de la RAM ou du CPU. Il s’agit d’ajuster sa configuration pour qu’il gère les connexions simultanées sans gaspiller les ressources.
Voici les clés techniques de “tuning” pour Apache et Nginx afin de maximiser leurs performances.
1. Nginx : L’as des connexions simultanées
Nginx utilise une architecture événementielle (asynchrone), ce qui le rend naturellement très performant pour le trafic de masse. Voici les paramètres à modifier dans /etc/nginx/nginx.conf :
Ajuster les Workers (Processus)
-
worker_processes auto;: Permet à Nginx de créer un processus par cœur de processeur disponible. -
worker_connections 1024;(ou plus, ex: 4096) : C’est le nombre maximum de connexions simultanées que chaque worker peut gérer.Calcul de la capacité max :
worker_processesworker_connections= Nombre max de clients simultanés.
Optimiser la gestion des fichiers et connexions
Nginx
events {
worker_connections 4096;
use epoll; # Optimisation spécifique à Linux pour gérer efficacement les connexions
multi_accept on; # Demande aux workers d'accepter toutes les nouvelles connexions d'un coup
}
http {
sendfile on; # Accélère l'envoi des fichiers en évitant la copie de données en mémoire tampon
tcp_nopush on; # Envoie les en-têtes HTTP en un seul paquet (idéal pour la bande passante)
tcp_nodelay on; # Force l'envoi immédiat des données (réduit la latence des petits paquets)
keepalive_timeout 30; # Réduit le temps d'attente des connexions inactives pour libérer les slots
keepalive_requests 500; # Nombre de requêtes autorisées par connexion persistante
}
2. Apache : Le passage obligatoire à MPM Event
Si vous utilisez encore le vieux module Prefork d’Apache, votre serveur s’effondrera sous le trafic de masse car il crée un processus lourd par utilisateur. Pour le trafic de masse, vous devez utiliser le module MPM Event (généralement couplé à PHP-FPM).
Modifiez le fichier de configuration du module (ex: /etc/apache2/mods-enabled/mpm_event.conf) :
Apache
<IfModule mpm_event_module>
StartServers 4
MinSpareThreads 25
MaxSpareThreads 75
ThreadLimit 64
ThreadsPerChild 25
MaxRequestWorkers 1000 # Le paramètre CRITIQUE (anciennement MaxClients)
MaxConnectionsPerChild 5000 # Relance les processus après X requêtes pour éviter les fuites de mémoire
</IfModule>
-
MaxRequestWorkers: C’est la limite absolue de requêtes simultanées traitées.Attention au calcul : Assurez-vous que votre RAM peut supporter ce nombre. Si un processus Apache consomme 50 Mo et que vous fixez
MaxRequestWorkersà 1000, Apache peut consommer jusqu’à 50 Go de RAM en pic de trafic.
3. Techniques globales indispensables (Valables pour les deux)
Le Keep-Alive : Trouver le bon équilibre
Le Keep-Alive permet de maintenir la connexion ouverte entre le serveur et le navigateur pour charger plusieurs fichiers (images, CSS, JS) sans rouvrir une connexion à chaque fois.
-
Trafic modéré : Activez-le (
KeepAlive Onoukeepalive_timeout 65). -
Trafic de masse extrême : Réduisez le timeout à 2 ou 5 secondes, ou désactivez-le si vous utilisez un CDN en amont. Cela libère instantanément les ressources pour les nouveaux visiteurs.
Activer la compression Gzip / Brotli
Compresser le texte (HTML, CSS, JS) avant de l’envoyer réduit drastiquement l’utilisation de la bande passante et accélère le temps de réponse (TTFB).
Nginx
# Exemple Nginx
gzip on;
gzip_types text/plain text/css application/json application/javascript text/xml;
gzip_comp_level 5; # Bon compromis entre réduction de taille et utilisation du CPU
Le Tuning Système (OS) au niveau de Linux
Souvent négligé, le système d’exploitation Linux limite par défaut le nombre de fichiers qu’un processus peut ouvrir simultanément (généralement 1024). Pour un trafic de masse, chaque connexion est un fichier ouvert.
Modifiez /etc/security/limits.conf pour augmenter les limites de l’utilisateur de votre serveur web (www-data ou nginx) :
Plaintext
www-data soft nofile 65536
www-data hard nofile 65536
Règle d’or : Après chaque modification, testez toujours la configuration (
nginx -touapachectl configtest) avant de redémarrer le service, et validez la tenue de charge avec un outil de stress-test comme ApacheBench (ab) ou k6.