Liste de contrôle essentielle pour l'optimisation des performances Nginx pour les sites Web à fort trafic

Pour tout site Web subissant un trafic important, Nginx s'impose comme un serveur Web et un proxy inverse puissant et très efficace. Cependant, le simple déploiement de Nginx ne suffit pas à garantir des performances optimales sous une charge lourde. Une configuration et un réglage appropriés sont essentiels pour libérer tout son potentiel, garantissant que vos applications Web restent rapides, réactives et fiables.

Cet article fournit une liste de contrôle complète des configurations et directives Nginx clés spécifiquement conçues pour optimiser les performances dans des environnements à fort trafic. Nous couvrirons tout, de la gestion des processus de travail et des connexions au réglage précis des tampons, en passant par la mise en œuvre de stratégies de mise en cache robustes et l'optimisation de la compression. En abordant systématiquement ces domaines, vous pouvez réduire considérablement la charge du serveur, améliorer la vitesse de livraison du contenu et optimiser l'expérience utilisateur globale.

1. Optimiser les processus de travail et les connexions

Nginx utilise un modèle de processus maître-travailleur (master-worker). Le processus maître lit la configuration et gère les processus de travail, qui traitent les requêtes client réelles. Une configuration appropriée de ces éléments peut améliorer considérablement la concurrence et l'utilisation des ressources.

worker_processes

Cette directive détermine le nombre de processus de travail que Nginx générera. En général, le réglage sur auto permet à Nginx de détecter le nombre de cœurs de CPU et de générer un nombre égal de processus de travail, ce qui est une bonne pratique courante.

worker_connections

Définit le nombre maximal de connexions simultanées qu'un seul processus de travail peut ouvrir. Ce paramètre, conjointement avec worker_processes, dicte le nombre total théorique de connexions concurrentes que Nginx peut gérer (worker_processes * worker_connections).

multi_accept

Permet à un processus de travail d'accepter plusieurs nouvelles connexions à la fois, évitant ainsi les goulots d'étranglement potentiels sous forte charge.

# /etc/nginx/nginx.conf

worker_processes auto; # Généralement défini sur 'auto' ou le nombre de cœurs de CPU

events {
    worker_connections 1024; # Ajuster en fonction de la capacité du serveur et de la charge prévue
    multi_accept on;
}

Astuce : Surveillez l'utilisation du CPU de votre serveur. Si worker_processes est défini sur auto et que votre utilisation du CPU est constamment élevée, vous pourriez envisager d'augmenter worker_connections ou de mettre à l'échelle les ressources de votre serveur.

2. Gestion efficace des connexions

L'optimisation de la manière dont Nginx gère les connexions réseau peut réduire la surcharge et améliorer la réactivité.

keepalive_timeout

Spécifie la durée pendant laquelle une connexion client de type « keep-alive » restera ouverte. La réutilisation des connexions réduit la surcharge liée à l'établissement de nouvelles connexions TCP et aux handshakes SSL. Une valeur courante est de 15 à 65 secondes, selon l'interactivité de votre application.

sendfile

Permet le transfert direct de données entre les descripteurs de fichiers, contournant la mise en mémoire tampon de l'espace utilisateur. Cela améliore considérablement les performances lors du service de fichiers statiques.

tcp_nopush

Fonctionne avec sendfile. Nginx tente d'envoyer l'en-tête HTTP et le début du fichier en un seul paquet. Après cela, il envoie les données dans des paquets complets. Cela réduit le nombre de paquets envoyés.

tcp_nodelay

Demande à Nginx d'envoyer les données dès qu'elles sont disponibles, sans mise en mémoire tampon. Ceci est bénéfique pour les applications interactives où une faible latence est plus critique que la maximisation du débit (par exemple, les applications de chat ou les mises à jour en temps réel).

http {
    keepalive_timeout 65; # Connexions keep-alive pendant 65 secondes
    sendfile on;
    tcp_nopush on; # Nécessite sendfile activé
    tcp_nodelay on; # Utile pour le proxying de contenu dynamique
}

3. Optimisation des tampons (Buffers)

Nginx utilise des tampons (buffers) pour gérer les requêtes des clients et les réponses des serveurs en amont (comme les serveurs d'applications). Dimensionner correctement ces tampons peut éviter les E/S disque inutiles, réduire l'utilisation de la mémoire et améliorer le débit.

Tampons client

• client_body_buffer_size: Taille du tampon pour les corps de requête client. Si un corps dépasse cette taille, il est écrit dans un fichier temporaire.
• client_header_buffer_size: Taille du tampon pour la première ligne et les en-têtes d'une requête client.
• large_client_header_buffers: Définit le nombre et la taille des tampons plus grands pour la lecture des en-têtes de requête client. Utile pour les requêtes avec de nombreux cookies ou de longs en-têtes de référent.

Tampons Proxy (pour les configurations de proxy inverse)

• proxy_buffers: Le nombre et la taille des tampons utilisés pour lire les réponses du serveur proxifié.
• proxy_buffer_size: La taille du premier tampon pour la lecture de la réponse. Généralement plus petit, car il ne contient souvent que des en-têtes.
• proxy_busy_buffers_size: La quantité maximale de tampons de réponse qui peuvent être dans l'état « occupé » (activement envoyés au client) à tout moment.

Tampons FastCGI (pour PHP-FPM, etc.)

• fastcgi_buffers: Le nombre et la taille des tampons utilisés pour lire les réponses du serveur FastCGI.
• fastcgi_buffer_size: La taille du premier tampon pour la lecture de la réponse.

http {
    # Tampons client
    client_body_buffer_size 1M; # Ajuster en fonction de la taille attendue du corps de la requête (par exemple, téléchargements de fichiers)
    client_header_buffer_size 1k;
    large_client_header_buffers 4 8k; # 4 tampons, chacun de 8 Ko

    # Tampons Proxy (si Nginx agit comme un proxy inverse)
    proxy_buffers 8 16k; # 8 tampons, chacun de 16 Ko
    proxy_buffer_size 16k; # Premier tampon de 16 Ko
    proxy_busy_buffers_size 16k; # Max 16 Ko de tampons occupés

    # Tampons FastCGI (si Nginx fonctionne avec PHP-FPM)
    fastcgi_buffers 116 8k; # 116 tampons, chacun de 8 Ko (par exemple pour WordPress)
    fastcgi_buffer_size 16k; # Premier tampon de 16 Ko
}

Avertissement : Définir des tampons trop petits peut entraîner des E/S disque et une dégradation des performances. Les définir trop grands peut consommer une mémoire excessive. Trouvez un équilibre grâce aux tests.

4. Mettre en œuvre des stratégies de mise en cache robustes

La mise en cache est l'un des moyens les plus efficaces d'améliorer les performances et de réduire la charge sur vos serveurs backend. Nginx peut servir de puissant cache de contenu.

proxy_cache_path

Définit le chemin d'accès au répertoire de cache, sa taille, le nombre de niveaux de sous-répertoires et la durée pendant laquelle les éléments inactifs restent dans le cache.

proxy_cache

Active la mise en cache pour un bloc location donné, en faisant référence à la zone définie dans proxy_cache_path.

proxy_cache_valid

Définit la durée pendant laquelle Nginx doit mettre en cache les réponses avec des codes d'état HTTP spécifiques.

proxy_cache_revalidate

Lorsqu'elle est activée, Nginx utilisera les en-têtes If-Modified-Since et If-None-Match pour revalider le contenu mis en cache auprès du backend, réduisant ainsi l'utilisation de la bande passante.

proxy_cache_use_stale

Ordonne à Nginx de servir du contenu périmé mis en cache si le serveur backend est en panne, ne répond pas ou rencontre des erreurs. Cela améliore considérablement la disponibilité.

expires

Définit les en-têtes Cache-Control et Expires pour la mise en cache côté client des fichiers statiques. Cela minimise les requêtes répétées vers Nginx.

http {
    # Définir une zone de cache proxy dans le bloc http
    proxy_cache_path /var/cache/nginx/my_cache levels=1:2 keys_zone=my_cache:10m inactive=60m max_size=10g;

    server {
        listen 80;
        server_name example.com;

        location / {
            proxy_pass http://my_upstream_backend;
            proxy_cache my_cache; # Activer la mise en cache pour cette localisation
            proxy_cache_valid 200 302 10m; # Mettre en cache les réponses réussies pendant 10 minutes
            proxy_cache_valid 404 1m; # Mettre en cache les 404 pendant 1 minute
            proxy_cache_revalidate on;
            proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
            add_header X-Cache-Status $upstream_cache_status; # Aide au débogage
        }

        # Mettre en cache les fichiers statiques dans le navigateur pendant une période plus longue
        location ~* \.(jpg|jpeg|gif|png|css|js|ico|woff|woff2|ttf|svg|eot)$ {
            expires 30d; # Cache pendant 30 jours
            add_header Cache-Control "public, no-transform";
            # Pour les fichiers statiques, envisager de les servir directement depuis Nginx s'ils ne sont pas proxifiés
            root /var/www/html;
        }
    }
}

5. Activer la compression Gzip

La compression des réponses avant de les envoyer aux clients peut réduire considérablement l'utilisation de la bande passante et améliorer les temps de chargement des pages, en particulier pour le contenu textuel.

gzip on

Active la compression gzip.

gzip_comp_level

Définit le niveau de compression (1-9). Le niveau 1 est le plus rapide avec moins de compression ; le niveau 9 est le plus lent avec une compression maximale. Le niveau 6 offre généralement un bon équilibre.

gzip_types

Spécifie les types MIME qui doivent être compressés. Inclure les types courants de texte, CSS, JavaScript et JSON.

gzip_min_length

Définit la longueur minimale d'une réponse (en octets) pour laquelle la compression doit être activée. Les petits fichiers ne bénéficient pas beaucoup de la compression et pourraient même être plus lents en raison de la surcharge de compression.

gzip_proxied

Ordonne à Nginx de compresser les réponses même si elles sont proxifiées. any est une valeur courante.

gzip_vary

Ajoute l'en-tête Vary: Accept-Encoding aux réponses, informant les proxys que la réponse peut différer en fonction de l'en-tête de requête Accept-Encoding.

http {
    gzip on;
    gzip_vary on;
    gzip_proxied any;
    gzip_comp_level 6; # Niveau de compression 1-9 (6 est un bon équilibre)
    gzip_buffers 16 8k; # 16 tampons, chacun de 8 Ko
    gzip_http_version 1.1; # Version HTTP minimale pour la compression
    gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript image/svg+xml;
    gzip_min_length 1000; # Ne compresser que les réponses supérieures à 1 Ko
}

6. Optimiser la journalisation (Logging)

Bien que les journaux soient essentiels pour la surveillance et le dépannage, une journalisation excessive ou non optimisée peut introduire des E/S disque importantes, en particulier sur les sites à fort trafic.

access_log

• Désactiver pour les actifs statiques : Pour le contenu statique très sollicité (images, CSS, JS), la désactivation de l'access_log peut économiser beaucoup d'E/S.
• Mise en mémoire tampon : Nginx peut mettre en mémoire tampon les entrées de journal avant de les écrire sur le disque, réduisant ainsi la fréquence des écritures sur le disque. Les paramètres buffer et flush sont utilisés ici.

error_log

Définir le niveau de journalisation approprié (crit, error, warn, info, debug). Pour la production, warn (avertissement) ou error (erreur) est généralement suffisant pour capturer les problèmes critiques sans inonder les journaux.

http {
    server {
        # Journal d'accès par défaut pour le contenu dynamique
        access_log /var/log/nginx/access.log main;

        location ~* \.(jpg|jpeg|gif|png|css|js|ico|woff|woff2|ttf|svg|eot)$ {
            access_log off; # Désactiver la journalisation pour les fichiers statiques courants
            expires 30d;
        }
    }

    # Exemple de journal d'accès mis en mémoire tampon pour le contexte HTTP principal
    # access_log /var/log/nginx/access.log main buffer=16k flush=5s;
    error_log /var/log/nginx/error.log warn; # Ne journaliser que les avertissements et au-delà
}

7. Régler les délais d'attente (Timeouts)

Des délais d'attente configurés de manière appropriée empêchent Nginx de conserver trop longtemps des connexions inactives, libérant ainsi des ressources.

Délais d'attente côté client

• client_body_timeout: Combien de temps Nginx attend qu'un client envoie le corps de la requête.
• client_header_timeout: Combien de temps Nginx attend qu'un client envoie l'en-tête de la requête.
• send_timeout: Combien de temps Nginx attend qu'un client accepte la réponse après qu'elle a été envoyée.

Délais d'attente Proxy/FastCGI (le cas échéant)

• proxy_connect_timeout: Délai d'attente pour l'établissement d'une connexion avec un serveur proxifié.
• proxy_send_timeout: Délai d'attente pour la transmission d'une requête au serveur proxifié.
• proxy_read_timeout: Délai d'attente pour la lecture d'une réponse du serveur proxifié.

http {
    client_body_timeout 15s; # Le client dispose de 15 secondes pour envoyer le corps
    client_header_timeout 15s; # Le client dispose de 15 secondes pour envoyer les en-têtes
    send_timeout 15s; # Nginx dispose de 15 secondes pour envoyer la réponse au client

    # Pour les scénarios de proxy
    proxy_connect_timeout 5s; # 5 secondes pour se connecter au serveur amont
    proxy_send_timeout 15s; # 15 secondes pour envoyer la requête au serveur amont
    proxy_read_timeout 15s; # 15 secondes pour lire la réponse du serveur amont

    # Pour les scénarios FastCGI
    fastcgi_connect_timeout 5s;
    fastcgi_send_timeout 15s;
    fastcgi_read_timeout 15s;
}

8. Optimisation SSL/TLS

Pour les sites compatibles HTTPS, l'optimisation des paramètres SSL/TLS est cruciale pour réduire la surcharge du CPU et améliorer les performances du handshake.

ssl_session_cache et ssl_session_timeout

Activez la mise en cache de la session SSL pour éviter le handshake TLS complet, coûteux en calcul, pour les connexions ultérieures provenant du même client.

ssl_protocols et ssl_ciphers

Utilisez des protocoles TLS modernes et robustes (comme TLSv1.2 et TLSv1.3) et des suites de chiffrement sécurisées. Priorisez les chiffrements côté serveur avec ssl_prefer_server_ciphers on.

ssl_stapling

Active l'agrafage OCSP (OCSP stapling), où Nginx récupère périodiquement la réponse OCSP de l'AC et l'« agrafe » au handshake SSL/TLS. Cela réduit la latence côté client en évitant une requête OCSP distincte.

server {
    listen 443 ssl;
    ssl_certificate /etc/nginx/ssl/your_domain.crt;
    ssl_certificate_key /etc/nginx/ssl/your_domain.key;

    ssl_session_cache shared:SSL:10m; # Cache partagé pour 10 Mo de données de session
    ssl_session_timeout 10m; # Les sessions expirent après 10 minutes

    ssl_protocols TLSv1.2 TLSv1.3; # Utiliser des protocoles modernes et sécurisés
    ssl_ciphers 'TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256';
    ssl_prefer_server_ciphers on;

    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 8.8.8.8 8.8.4.4 valid=300s; # Spécifier les résolveurs DNS pour les requêtes OCSP
    resolver_timeout 5s;
}

9. Cache des fichiers ouverts (Open File Cache)

Nginx peut mettre en cache les descripteurs de fichiers pour les fichiers fréquemment consultés, réduisant ainsi le besoin d'appels système répétés pour ouvrir et fermer les fichiers.

open_file_cache

Active le cache, spécifiant le nombre maximum d'éléments et la durée pendant laquelle les éléments inactifs restent.

open_file_cache_valid

Définit la fréquence à laquelle le cache doit vérifier la validité de ses éléments.

open_file_cache_min_uses

Spécifie le nombre minimum de fois où un fichier doit être consulté dans le temps inactive pour rester dans le cache.

open_file_cache_errors

Détermine si Nginx doit mettre en cache les erreurs lors de l'ouverture des fichiers.

http {
    open_file_cache max=100000 inactive=60s; # Mettre en cache jusqu'à 100 000 descripteurs de fichiers pendant 60s
    open_file_cache_valid 80s; # Vérifier la validité toutes les 80 secondes
    open_file_cache_min_uses 1; # Mettre en cache les fichiers utilisés au moins une fois
    open_file_cache_errors on; # Mettre en cache les erreurs liées à l'ouverture des fichiers
}

Conclusion

L'optimisation des performances de Nginx est un processus continu, et non une configuration ponctuelle. Cette liste de contrôle fournit un point de départ solide pour optimiser vos sites Web à fort trafic. N'oubliez pas que la configuration « parfaite » dépend fortement de votre application spécifique, des modèles de trafic et des ressources du serveur. Testez toujours les modifications dans un environnement de staging avant de les déployer en production, et surveillez en permanence vos instances Nginx et vos serveurs backend à l'aide d'outils tels que la surveillance d'activité en direct de Nginx Plus, Prometheus, Grafana ou des outils système de base (par exemple, top, iostat, netstat).

En appliquant méticuleusement ces optimisations et en les adaptant à votre environnement, vous pouvez vous assurer que Nginx fournit du contenu avec une vitesse, une efficacité et une fiabilité exceptionnelles, même sous les charges les plus exigeantes.