Optimisation des performances Nginx : astuces pour des sites web plus rapides

Les sites lents proviennent généralement d'une poignée de causes : réponses en amont coûteuses, en-têtes de cache manquants, ressources surdimensionnées, workers bloqués, ou un serveur configuré avec les valeurs par défaut plutôt qu'adapté à votre trafic. L'optimisation des performances Nginx fonctionne mieux lorsque vous mesurez d'abord, modifiez un paramètre à la fois et gardez la configuration lisible.

Utilisez les exemples ci-dessous comme points de départ, puis testez-les en charge avec votre propre application. Un serveur de fichiers statiques, un site WordPress/PHP-FPM et un proxy inverse d'API nécessitent des compromis différents.

Comprendre les goulots d'étranglement des performances Nginx

Commencez par identifier le goulot d'étranglement. Les causes courantes incluent :

Utilisation du CPU : Une charge CPU élevée ralentit le traitement des requêtes, la compression et le travail TLS.
Pression mémoire : Le swap nuit gravement à la latence.
E/S réseau : Des liaisons lentes, de petites fenêtres en amont ou des pertes de paquets peuvent dominer le temps de réponse.
E/S disque : Les fichiers statiques, les fichiers de cache et les journaux touchent toujours le stockage.
Latence en amont : Nginx peut être rapide tandis que votre serveur d'application est lent.

Des outils comme top, htop, iostat, ss, les journaux d'accès et le module stub_status de Nginx peuvent vous aider à décider quoi ajuster.

Techniques d'optimisation de base de Nginx

Processus workers et connexions

La directive worker_processes contrôle le nombre de processus workers que Nginx démarre. auto est une valeur par défaut pratique car Nginx détecte les cœurs CPU disponibles.

# Définir worker_processes sur le nombre de cœurs CPU
worker_processes auto;

Dans chaque processus worker, worker_connections limite le nombre de connexions simultanées que ce worker peut ouvrir. La limite supérieure approximative est worker_processes * worker_connections, mais la capacité réelle dépend également des connexions en amont, des limites de fichiers ouverts, du comportement keep-alive et des limites du système d'exploitation.

# Augmenter worker_connections pour les sites à fort trafic
worker_connections 1024;

Si vous voyez Too many open files, augmenter worker_connections seul ne suffit pas. Vérifiez également la limite de descripteurs de fichiers du service, souvent contrôlée par LimitNOFILE de systemd ou les limites du shell.

Stratégies de mise en cache

La mise en cache est généralement l'optimisation des performances Nginx ayant le plus d'impact car elle évite les travaux répétés.

Mise en cache du navigateur

Demandez aux navigateurs de mettre en cache les ressources statiques versionnées telles que les images, CSS et JavaScript. Utilisez des durées de vie longues uniquement lorsque les noms de fichiers changent lors du déploiement, comme app.8f3c1.css.

location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
    expires 30d;
    add_header Cache-Control "public";
}

Mise en cache proxy

Si Nginx est un proxy inverse, il peut mettre en cache certaines réponses du backend. Cela fonctionne bien pour les pages publiques, les réponses API avec des règles de fraîcheur claires et les pages coûteuses qui ne varient pas par utilisateur.

Tout d'abord, définissez une zone de cache dans le bloc http :

http {
    # ... autres configurations http ...
    proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=1g inactive=60m;
    # ...
}

/var/cache/nginx : Le répertoire où les fichiers de cache seront stockés.
levels=1:2 : Définit la structure de répertoires pour le cache.
keys_zone=my_cache:10m : Crée une zone mémoire partagée nommée my_cache avec une taille de 10 Mo pour stocker les clés de cache.
max_size=1g : Définit la taille maximale du cache.
inactive=60m : Supprime les entrées de cache qui n'ont pas été consultées pendant 60 minutes.

Ensuite, activez la mise en cache dans votre bloc location :

location / {
    proxy_pass http://your_backend_app;
    proxy_cache my_cache;
    proxy_cache_valid 200 302 10m; # Mettre en cache les réponses 200 et 302 pendant 10 minutes
    proxy_cache_valid 404 1m;     # Mettre en cache les réponses 404 pendant 1 minute
    add_header X-Cache-Status $upstream_cache_status;
}

add_header X-Cache-Status $upstream_cache_status; est utile pour le débogage, indiquant si une requête a été un succès de cache, un échec ou un contournement.

Ne mettez pas en cache les pages personnalisées à moins que votre clé de cache ne tienne compte des données qui modifient la réponse. Par exemple, un tableau de bord connecté doit généralement contourner le cache proxy, tandis que /assets/logo.png peut être mis en cache pendant une longue période.

Compression

La compression réduit la taille de transfert pour les réponses textuelles telles que HTML, CSS, JavaScript, JSON et XML. Elle n'aide pas beaucoup pour les fichiers déjà compressés comme JPEG, PNG, MP4 ou de nombreux formats d'archive.

http {
    # ...
    gzip on;
    gzip_vary on;
    gzip_proxied any;
    gzip_comp_level 6;
    gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
    # ...
}

gzip on; : Active la compression Gzip.
gzip_vary on; : Ajoute l'en-tête Vary: Accept-Encoding, important pour les proxys de cache.
gzip_proxied any; : Compresse également les réponses pour les requêtes proxyfiées.
gzip_comp_level 6; : Définit le niveau de compression (1-9, plus élevé signifie meilleure compression mais plus de CPU).
gzip_types ...; : Spécifie les types MIME à compresser.

Brotli peut bien compresser les ressources textuelles, mais les builds Nginx open source standard ne sont pas tous livrés avec le support Brotli. Vérifiez votre package ou ensemble de modules avant d'ajouter des directives Brotli.

Gestion des connexions et Keep-Alive

La directive keepalive_timeout contrôle la durée pendant laquelle une connexion client inactive reste ouverte. Réutiliser une connexion évite des négociations TCP et TLS supplémentaires, mais les connexions inactives consomment toujours des ressources.

http {
    # ...
    keepalive_timeout 65;
    keepalive_requests 1000;
    # ...
}

keepalive_timeout 65; : Définit le délai d'attente keep-alive à 65 secondes.
keepalive_requests 1000; : Définit le nombre maximum de requêtes pouvant être effectuées sur une seule connexion keep-alive.

Pour les API avec de nombreuses requêtes courtes, le keep-alive aide. Pour un petit serveur avec de nombreux clients inactifs, un délai d'attente plus court peut être préférable.

Tampons et limites de taille des requêtes

Nginx utilise des tampons pour les corps des clients et les réponses proxyfiées. Les valeurs par défaut conviennent à de nombreux sites, mais les applications avec beaucoup d'uploads et les grands en-têtes en amont peuvent nécessiter des paramètres explicites.

http {
    # ...
    client_body_buffer_size 10K;
    client_max_body_size 8M;
    proxy_buffers 8 16k;
    proxy_buffer_size 16k;
    proxy_connect_timeout 60;
    proxy_send_timeout 60;
    proxy_read_timeout 60;
    # ...
}

client_body_buffer_size : Taille du tampon utilisé pour lire le corps de la requête client.
client_max_body_size : Taille maximale autorisée du corps de la requête client.
proxy_buffers, proxy_buffer_size : Contrôle la mise en tampon lorsque Nginx agit comme un proxy.

Évitez de copier aveuglément des extraits de tampon. Si vous voyez upstream sent too big header, enquêtez sur les en-têtes en amont avant d'augmenter proxy_buffer_size. Si les uploads échouent avec 413 Request Entity Too Large, définissez client_max_body_size sur la taille que votre application supporte réellement.

Optimisation TLS

Pour les sites HTTPS, les paramètres TLS affectent à la fois la latence et la sécurité.

Reprise de session : Utilisez un cache de session pour accélérer les connexions répétées.
```
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_session_tickets off;
```
Versions TLS : Activez TLS 1.2 et TLS 1.3 sauf si vos exigences de compatibilité disent le contraire.
OCSP stapling : Peut réduire les allers-retours de validation de certificat lorsque votre chaîne de certificats le supporte.
```
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
```

Service de fichiers statiques

Nginx est performant pour servir des fichiers statiques. Ces directives sont courantes dans le bloc http :

sendfile : Permet au noyau de copier les données du fichier directement vers le socket sur les systèmes supportés.
```
sendfile on;
```
tcp_nopush et tcp_nodelay : Ajustent le comportement d'envoi des paquets pour les charges de travail HTTP courantes.
```
tcp_nopush on;
tcp_nodelay on;
```

Surveillance et tests

Après chaque modification, testez et comparez. Les outils utiles incluent :

Nginx stub_status : Connexions actives, connexions acceptées, connexions traitées et requêtes.
top/htop : Pression CPU et mémoire.
iostat : E/S disque.
WebPageTest ou PageSpeed Insights : Performances côté navigateur.
wrk, ab ou hey : Tests de charge locaux contre des points de terminaison contrôlés.

Conservez une copie de la configuration précédente, exécutez sudo nginx -t, rechargez, et comparez la latence, le taux d'erreur, le CPU et le temps de réponse en amont. La meilleure optimisation des performances Nginx est celle que vos mesures peuvent prouver.

En pratique

Commencez par la mesure, puis corrigez le plus gros goulot d'étranglement en premier. Pour la plupart des sites web, cela signifie définir des limites de workers raisonnables, ajouter la mise en cache du navigateur pour les ressources statiques, activer gzip, mettre en cache les réponses en amont sûres et surveiller les journaux après chaque rechargement.