Flux de traitement HTTP Nginx : optimisation de la configuration

La configuration par défaut de Nginx est conçue pour la compatibilité, et non pour les performances. Avec un réglage approprié, un seul serveur peut traiter entre 50 000 et 80 000 requêtes par seconde. Ce guide couvre les paramètres les plus importants : processus de travail, connexions, keepalive, mise en mémoire tampon, équilibrage de charge, et comment vérifier vos modifications à l'aide de tests de performance.

Comment Nginx traite les requêtes HTTP

Nginx traite les requêtes en plusieurs phases distinctes, chacune consommant des ressources système. Comprendre ce flux vous aide à cibler les bons paramètres.

Tout commence au niveau du noyau. Les connexions entrantes sont placées dans les files d’attente SYN et ACCEPT, puis récupérées par les processus de travail Nginx. Une fois acceptée, le processus de travail analyse la requête HTTP à partir du tampon du noyau. Le trafic TLS rend cette étape plus gourmande en ressources CPU.

Ensuite, Nginx associe la requête à un serveur virtuel à l'aide de l'en-tête Host et de la combinaison IP/port, puis résout l'URI en un bloc de localisation via une correspondance par préfixe ou par expression régulière.

Pour le contenu dynamique, Nginx transfère la requête vers un backend (FastCGI, proxy). Cette phase de communication en amont tire largement parti des connexions persistantes. Sans keepalive en amont, Nginx ouvre une nouvelle connexion TCP par requête, ce qui ajoute de la latence et une charge CPU supplémentaire.

Si proxy_buffering est activé, Nginx lit l'intégralité de la réponse en amont en mémoire avant de la transmettre au client. Cela libère le worker, qui peut alors traiter immédiatement de nouvelles requêtes. Enfin, lors de la transmission de la sortie, l'activation de sendfile permet des transferts sans copie, ce qui peut faire passer le débit d'environ 6 Gbps à 30 Gbps.

Chaque phase consomme des tampons mémoire, des descripteurs de fichiers et des cycles CPU. Les sections ci-dessous traitent de chaque goulot d'étranglement.

Processus de travail et connexions

Commencez par worker_processes auto; dans votre contexte principal. Cela permet d'adapter le nombre de workers au nombre de cœurs de votre processeur. Sur un VPS avec un nombre limité de cœurs, définissez ce nombre manuellement (par exemple worker_processes 2;). Si votre charge de travail est gourmande en mémoire, envisagez de réduire le nombre de workers pour éviter de surcharger la RAM.

Activez worker_cpu_affinity auto; pour affecter chaque worker à un cœur spécifique. Cela réduit les échecs de cache et les changements de contexte. Disponible depuis Nginx 1.9.10.

Limites de connexion

La worker_connections directive définit le nombre de connexions simultanées que chaque worker peut gérer. La capacité totale est de worker_processes × worker_connections. La valeur par défaut de 512 ou 1 024 est trop faible pour une utilisation en production. Réglez-la sur 2 048 ou 4 096 par worker pour les sites à fort trafic.

Chaque connexion nécessite au moins un descripteur de fichier. Dans une configuration de proxy inverse, chaque connexion en utilise deux (un pour le client, un pour l’amont). Réglez worker_rlimit_nofile au moins le double de votre worker_connections valeur en prévoyant une marge. Pour worker_connections 4096;, utilisez worker_rlimit_nofile 10000; ou plus

Au niveau du système, augmentez fs.file-max la valeur /etc/sysctl.conf au moins 500 000 et définissez LimitNOFILE=65535.

Enfin, ajoutez multi_accept on; dans le bloc events afin que les workers acceptent toutes les connexions en attente en une seule fois plutôt qu'une par une.

Timeouts et Keepalive

Keepalive client

La keepalive_timeout directive contrôle la durée pendant laquelle les connexions client inactives restent ouvertes. Pour les serveurs à fort trafic, une durée de 30 à 65 secondes convient bien. Utilisez la forme à deux paramètres :

keepalive_timeout 65s 60s;

La première valeur correspond au délai d'expiration côté serveur. La seconde envoie un Keep-Alive: timeout=60 en-tête au client. Définir la valeur côté client à un niveau légèrement inférieur permet d’éviter les conditions de concurrence où les navigateurs tentent de réutiliser des connexions que Nginx a déjà fermées.

La keepalive_requests directive limite le nombre de requêtes qu’une connexion unique peut traiter avant d’être fermée. La valeur par défaut est 1 000 (augmentée de 100 dans la version 1.19.10). Pour les backends stables, augmentez cette valeur à 10 000 afin de réduire le renouvellement des connexions.

Les délais d'expiration du proxy

proxy_connect_timeout définit le temps pendant lequel Nginx attend pour établir une connexion avec le backend. La valeur par défaut est de 60 secondes. Réduisez-la à 5 à 10 secondes pour un basculement rapide.

proxy_read_timeout définit le temps d'attente de Nginx entre deux lectures successives en amont. Alignez-le sur le délai d'exécution de votre backend. Si celui de PHP-FPM request_terminate_timeout est de 120 secondes, réglez proxy_read_timeout à au moins 120 secondes pour éviter des erreurs 504 prématurées.

proxy_send_timeout contrôle l'intervalle entre les écritures successives vers l'upstream. La valeur par défaut de 60 secondes convient généralement, sauf si vous envoyez des corps de requêtes volumineux.

En règle générale, proxy_connect_timeout devrait toujours être le plus court des trois.

Dimensionnement de la mémoire tampon

client_body_buffer_size détermine la quantité de données du corps d'une requête entrante que Nginx conserve en mémoire. La valeur par défaut de 8 Ko ou 16 Ko permet de traiter les soumissions de formulaires simples, mais les téléchargements de fichiers déborderont sur le disque. Augmentez-la à 128 Ko pour les téléchargements de petite à moyenne taille. Augmentez client_max_body_size la valeur par défaut de 1 Mo si les utilisateurs téléchargent des fichiers plus volumineux.

proxy_buffer_size traite les en-têtes de réponse séparément du corps. La valeur par défaut de 4 Ko ou 8 Ko fonctionne généralement, mais les applications avec des Set-Cookie (fréquents dans le commerce électronique) peuvent dépasser cette limite, provoquant des erreurs 502. Mesurez la taille réelle de vos en-têtes :

curl -s -w '%{size_header}' -o /dev/null http://your-upstream-url

arrondissez à l'incrément de 4 ko le plus proche.

proxy_buffers définit le nombre et la taille des tampons pour le corps de la réponse. La valeur par défaut (8 tampons de 4 Ko ou 8 Ko, soit un total de 32 Ko à 64 Ko) ne suffira pas pour une réponse JSON volumineuse. Mesurez votre réponse type la plus volumineuse avec curl et configurez suffisamment de tampons pour la conserver entièrement en mémoire vive.

Comportement de mise en mémoire tampon du proxy

Avec proxy_buffering on (valeur par défaut), Nginx lit l'intégralité de la réponse en amont en mémoire avant de l'envoyer au client. Cela permet aux serveurs backend de passer immédiatement à de nouvelles requêtes.

Définissez proxy_busy_buffers_size sur au moins proxy_buffer_size plus un tampon, mais moins que la taille totale de votre pool de tampons. Pour proxy_buffers 8 16k (128 Ko au total), maintenez proxy_busy_buffers_size en dessous de 112 ko.

Pour les points de terminaison en temps réel tels que les Server-Sent Events ou le long-polling, désactivez la mise en mémoire tampon proxy_buffering off dans un bloc spécifique à l'emplacement. Appliquez cette mesure de manière sélective aux /stream ou /events , et non de manière globale.

Équilibrage de charge et keepalive en amont

Par défaut, Nginx ouvre une nouvelle connexion TCP pour chaque requête proxy. Chaque handshake ajoute 10 à 100 ms de latence, le TLS ajoutant 10 à 50 ms supplémentaires. Le keepalive en amont maintient un pool de connexions persistantes afin d'éliminer cette surcharge.

Trois paramètres sont requis :

upstream backend {
    server 10.0.1.10:8080;
    server 10.0.1.11:8080;
    keepalive 128;
}
 
server {
    location / {
        proxy_pass http://backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
    }
}

La keepalive valeur définit le nombre maximal de connexions inactives par worker. Calculez la taille optimale du pool comme suit : (workers × target concurrency) / upstream nodes.

Réglez la valeur « upstream » keepalive_timeout sur 60 à 120 secondes pour correspondre aux paramètres de votre backend et gérer les pics de trafic.

Stratégies d'équilibrage

Nginx prend en charge plusieurs méthodes d’équilibrage de charge. La méthode Round-robin (par défaut) distribue les requêtes de manière séquentielle. least_conn achemine vers le serveur ayant le moins de connexions actives, ce qui convient aux charges de travail avec des durées de requête variables. ip_hash assure la persistance de session en acheminant la même adresse IP de client vers le même backend.

Utilisez le weight paramètre lorsque les serveurs ont des capacités différentes :

upstream backend {
    least_conn;
    server 10.0.1.10:8080 weight=3;
    server 10.0.1.11:8080;
    server 10.0.1.12:8080 backup;
    keepalive 128;
}

Le serveur pondéré reçoit trois fois plus de trafic. Le backup serveur ne s'active que si tous les serveurs principaux sont hors service. Configurez max_fails et fail_timeout pour les contrôles d'intégrité passifs, et utilisez max_conns pour limiter le nombre de connexions simultanées par backend.

Tests et surveillance

Mesurez toujours les performances de référence avant d'apporter la moindre modification. Après chaque modification, effectuez à nouveau un benchmark. Effectuez une modification à la fois.

Vérifiez la syntaxe de votre configuration avec nginx -t avant de recharger. Effectuez les tests de performance à partir d'une machine distincte pour éviter les conflits de ressources.

wrk est l'outil standard pour les tests de charge HTTP :

wrk -t4 -c200 -d30s http://your-server.com/

Suivez le nombre de requêtes par seconde, la latence moyenne, la latence maximale et le débit de transfert. Apache Bench convient pour des tests plus simples :

ab -n 50000 -c 40 http://your-server.com/

Surveillance continue

Activez le stub_status module pour surveiller les connexions actives en temps réel via curl http://localhost/nginx_status.

Ajoutez des variables de chronométrage à votre format de journal pour identifier où se produisent les retards :

• $request_time pour la durée totale de la requête
• $upstream_connect_time pour le temps de connexion au backend
• $upstream_response_time pour le temps total de traitement du backend

Vérifiez les journaux d'erreurs pour détecter les problèmes de mémoire tampon avec journalctl -u nginx --no-pager | grep "temporary file". Si les réponses sont enregistrées sur le disque, vos proxy_buffers sont trop petites. Recherchez les erreurs « trop de fichiers ouverts », qui indiquent worker_rlimit_nofile doit être augmenté.

Réduisez les E/S des journaux grâce à la mise en mémoire tampon :

access_log /var/log/nginx/access.log combined buffer=64k flush=5s;

Utilisez ss -tn state established dst [backend_ip] lors des tests de charge pour vérifier que les connexions sont réutilisées et ne s'accumulent pas en TIME_WAIT.

Pour les serveurs dédiés et l'hébergement VPS optimisés pour les charges de travail hautes performances, consultez la section Serveurs FDC.