Optimisation des performances Nginx sur un VPS

14 min de lecture·Matthieu·vpslinuxperformancenginx|

Optimisez Nginx pour le trafic en production sur un VPS Linux. Worker processes, compression, cache, HTTP/2, TLS et paramètres kernel avec benchmarks wrk.

Une installation Nginx par défaut gère un trafic modéré sans problème. Mais les réglages par défaut sont conservateurs. Sur un VPS 4 vCPU avec 8 Go de RAM, vous pouvez servir bien plus de requêtes par seconde en ajustant les worker processes, la compression, le cache et les paramètres kernel. Ce guide passe en revue chaque couche, avec des benchmarks pour prouver que chaque changement compte.

On suppose que Nginx est déjà installé et sert du trafic. Si ce n'est pas le cas, commencez par le guide d'administration Nginx sur VPS.

Tous les exemples ciblent Nginx mainline sur Debian 12 ou Ubuntu 24.04. La structure des fichiers de configuration est couverte dans le guide sur la structure des fichiers de configuration Nginx.

Comment établir une baseline de performance pour Nginx ?

Avant de modifier quoi que ce soit, mesurez les performances actuelles avec wrk. Cela vous donne une baseline à comparer après le tuning. Sans chiffres, vous naviguez à l'aveugle.

Installez wrk sur une machine séparée (votre poste de travail ou un autre VPS). Ne lancez jamais un benchmark depuis le serveur que vous testez. L'outil de benchmark et le serveur web se disputent le CPU, et les résultats deviennent inexploitables.

apt install wrk

Lancez un test de 30 secondes avec 4 threads et 200 connexions sur une page statique :

wrk -t4 -c200 -d30s https://your-server.example.com/

Running 30s test @ https://your-server.example.com/
  4 threads and 200 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    12.34ms    5.67ms  89.12ms   78.45%
    Req/Sec     4.12k   312.45     5.23k    72.50%
  493440 requests in 30.01s, 1.92GB read
Requests/sec:  16442.18
Transfer/sec:     65.52MB

Notez quatre chiffres : requests/sec, latence moyenne, latence max et transfer/sec. C'est votre baseline.

Combien de worker processes et de connexions Nginx doit-il utiliser ?

Réglez worker_processes auto pour créer un worker par cœur CPU. Sur un VPS 4 vCPU, cela donne 4 workers. Chaque worker est mono-thread et gère les connexions de façon indépendante via epoll. Un worker par cœur évite le surcoût des changements de contexte.

La formule pour le nombre maximal de connexions simultanées :

max connexions = worker_processes x worker_connections

vCPUs worker_processes worker_connections Max connexions
1 1 2048 2 048
2 2 2048 4 096
4 4 2048 8 192
8 8 2048 16 384

Chaque connexion consomme un descripteur de fichier. Réglez worker_rlimit_nofile plus haut que worker_connections pour éviter d'atteindre la limite de l'OS. Une valeur sûre est worker_connections * 2, ce qui prend en compte les connexions upstream en mode proxy.

Éditez /etc/nginx/nginx.conf :

worker_processes auto;
worker_cpu_affinity auto;
worker_rlimit_nofile 8192;

events {
    worker_connections 4096;
    use epoll;
    multi_accept on;
}

worker_cpu_affinity auto attache chaque worker à un cœur CPU, réduisant les défauts de cache liés à la migration de processus. multi_accept on permet à un worker d'accepter toutes les connexions en attente d'un coup au lieu d'une à la fois. use epoll est la valeur par défaut sous Linux, mais mieux vaut être explicite.

La directive accept_mutex est à off par défaut depuis Nginx 1.11.3, car les kernels Linux 4.5+ supportent EPOLLEXCLUSIVE, qui distribue les connexions entre workers sans mutex. Laissez-la désactivée.

nginx -t

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

systemctl reload nginx

Quelles directives TCP améliorent le débit de Nginx ?

Trois directives fonctionnent ensemble pour optimiser l'envoi de données par Nginx sur TCP. sendfile contourne le tampon en espace utilisateur en copiant les données directement entre descripteurs de fichiers dans le kernel. tcp_nopush regroupe les en-têtes de réponse et le début d'un fichier dans un seul paquet TCP. tcp_nodelay désactive l'algorithme de Nagle pour que les petits paquets (comme la fin d'une réponse) soient envoyés immédiatement.

Ajoutez ces directives dans le bloc http de /etc/nginx/nginx.conf :

http {
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;

    #...directives existantes...
}

sendfile fait la plus grande différence pour le service de fichiers statiques. Sans cette directive, Nginx lit le fichier dans un tampon, puis écrit le tampon vers le socket. Deux copies. Avec sendfile, le kernel fait un transfert zero-copy. Sur un serveur de fichiers statiques chargé, cela seul réduit l'utilisation CPU de façon notable.

tcp_nopush et tcp_nodelay ne sont pas contradictoires. Nginx applique tcp_nopush pendant la construction de la réponse, puis bascule sur tcp_nodelay pour le dernier paquet. Résultat : moins de paquets au total, sans délai sur le dernier.

Comment régler les connexions keepalive pour Nginx ?

Les connexions keepalive permettent à un client de réutiliser une connexion TCP pour plusieurs requêtes HTTP. Cela évite le surcoût des handshakes TCP et de la négociation TLS à chaque requête. Un seul chargement de page peut déclencher 20 à 50 sous-requêtes pour le CSS, le JS, les images et les polices.

http {
    keepalive_timeout 65;
    keepalive_requests 1000;

    #...directives existantes...
}

keepalive_timeout 65 ferme les connexions inactives après 65 secondes. Trop haut gaspille des descripteurs de fichiers sur des clients inactifs. Trop bas force des reconnexions. 65 secondes est un défaut raisonnable pour la plupart des charges.

keepalive_requests 1000 autorise jusqu'à 1 000 requêtes par connexion avant que Nginx ne la ferme. La valeur par défaut est 1000 depuis Nginx 1.19.10. Si vous êtes derrière un load balancer qui envoie beaucoup de requêtes par connexion, montez à 10000.

Keepalive upstream

Si Nginx sert de proxy vers un backend (Node.js, Python, Go), les connexions keepalive upstream évitent à Nginx d'ouvrir une nouvelle connexion TCP vers le backend à chaque requête. C'est là que la plupart des configurations proxy perdent du temps.

upstream backend {
    server 127.0.0.1:3000;
    keepalive 64;
}

server {
    location / {
        proxy_pass http://backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
    }
}

keepalive 64 garde 64 connexions inactives ouvertes vers le backend par worker. proxy_http_version 1.1 est requis car le keepalive est une fonctionnalité HTTP/1.1. L'en-tête Connection vide efface le Connection: close du client pour que Nginx ne le transmette pas au backend.

Pour en savoir plus sur la configuration proxy, voir le guide sur le reverse proxy Nginx.

Comment dimensionner les tampons proxy de Nginx ?

Quand Nginx sert de proxy, il met en tampon la réponse du backend. Si le tampon est trop petit, Nginx écrit la réponse dans un fichier temporaire sur disque. Les I/O disque sont des ordres de grandeur plus lentes que la RAM.

http {
    proxy_buffer_size 16k;
    proxy_buffers 4 32k;
    proxy_busy_buffers_size 64k;

    client_body_buffer_size 16k;
    client_header_buffer_size 1k;
    large_client_header_buffers 4 8k;

    #...directives existantes...
}

proxy_buffer_size 16k gère les en-têtes de réponse du backend. La plupart des en-têtes tiennent dans 4k-8k, mais les applications qui définissent beaucoup de cookies ou d'en-têtes personnalisés ont besoin de plus. 16k est sûr sans être gaspilleur.

proxy_buffers 4 32k alloue 4 tampons de 32k chacun (128k au total par connexion) pour le corps de la réponse. Dimensionnez-les selon la taille typique de vos réponses. Les réponses API de moins de 100k tiennent largement. Si vous servez de gros payloads, augmentez le nombre de tampons plutôt que leur taille.

proxy_busy_buffers_size 64k contrôle la quantité de données en tampon que Nginx peut envoyer au client tout en continuant à lire le backend. Elle ne doit pas dépasser le total de proxy_buffers.

Surveillez ceci dans votre log d'erreur :

an upstream response is buffered to a temporary file

Si vous le voyez souvent, augmentez proxy_buffers. Vérifiez le log :

journalctl -u nginx --no-pager | grep "temporary file"

Comment configurer le cache de fichiers statiques dans Nginx ?

Le cache de fichiers statiques indique aux navigateurs de stocker les assets localement. Cela élimine totalement les requêtes répétées. Pour les assets avec des noms hashés (comme app.a1b2c3.js), utilisez une expiration agressive. Pour le HTML, gardez-la courte.

server {
    location ~* \.(css|js|woff2|woff|ttf|svg)$ {
        expires 1y;
        add_header Cache-Control "public, immutable";
        access_log off;
    }

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

    location ~* \.html$ {
        expires 1h;
        add_header Cache-Control "public, no-cache";
    }
}

immutable indique au navigateur de ne pas revalider l'asset du tout. N'utilisez cela que pour les noms de fichiers fingerprinted. access_log off sur les assets statiques réduit les I/O disque liées aux logs.

Pour les en-têtes de cache et leur interaction avec les en-têtes de sécurité, voir.

open_file_cache

Nginx peut mettre en cache les descripteurs de fichiers, les dates de modification et les vérifications d'existence pour les fichiers fréquemment accédés. Cela évite les appels système stat() et open() répétés.

http {
    open_file_cache max=10000 inactive=30s;
    open_file_cache_valid 60s;
    open_file_cache_min_uses 2;
    open_file_cache_errors on;
}

max=10000 conserve jusqu'à 10 000 entrées. Dimensionnez ce chiffre selon le nombre de fichiers statiques que vous servez. Si vous servez 500 fichiers, max=1000 suffit. Si vous servez 50 000 assets depuis un CDN origin, augmentez en conséquence.

inactive=30s évince les entrées non accédées pendant 30 secondes. open_file_cache_min_uses 2 ne met en cache que les fichiers accédés au moins deux fois pendant la fenêtre inactive. Cela empêche les requêtes ponctuelles de polluer le cache.

open_file_cache_errors on met aussi en cache les réponses 404. Si un client redemande un fichier inexistant, Nginx répond depuis le cache au lieu de solliciter le système de fichiers à chaque fois.

Comment activer la compression gzip et Brotli dans Nginx ?

Gzip au niveau 4-6 offre le meilleur rapport entre coût CPU et taux de compression. Au-delà du niveau 6, on gagne moins de 2 % de compression en doublant le temps CPU. Brotli au niveau 4 atteint généralement une meilleure compression que gzip au niveau 9, pour un coût CPU similaire.

Gzip

http {
    gzip on;
    gzip_comp_level 5;
    gzip_min_length 256;
    gzip_vary on;
    gzip_proxied any;
    gzip_types
        text/plain
        text/css
        text/javascript
        application/javascript
        application/json
        application/xml
        application/xml+rss
        image/svg+xml;
}

gzip_min_length 256 ignore les fichiers de moins de 256 octets. Compresser de petits fichiers peut produire une sortie plus volumineuse que l'entrée à cause des en-têtes gzip. gzip_vary on ajoute un en-tête Vary: Accept-Encoding pour que les caches stockent séparément les versions compressées et non compressées. gzip_proxied any compresse les réponses même quand la requête est passée par un proxy.

Brotli

Brotli offre une compression 15-25 % meilleure que gzip sur les assets textuels. Il est supporté par tous les navigateurs modernes. Sur Ubuntu 24.04 avec le paquet Nginx de la distribution, installez le module directement :

apt install libnginx-mod-http-brotli-filter libnginx-mod-http-brotli-static

Sur Debian 12 ou avec Nginx mainline depuis nginx.org, le module Brotli n'est pas inclus. Vous devez le compiler comme module dynamique ou utiliser un dépôt tiers. Le dépôt ngx_brotli contient les instructions de compilation.

Une fois le module chargé, configurez-le :

http {
    brotli on;
    brotli_comp_level 4;
    brotli_static on;
    brotli_types
        text/plain
        text/css
        text/javascript
        application/javascript
        application/json
        application/xml
        image/svg+xml;
}

brotli_static on sert les fichiers pré-compressés .br s'ils existent. Cela vous permet de compresser les assets au moment du build avec un niveau de compression plus élevé (par exemple 11) sans payer le coût CPU à l'exécution.

brotli_comp_level 4 est le point d'équilibre pour la compression dynamique. Contrairement à gzip, les niveaux 1-4 de Brotli sont rapides. Les niveaux 5+ deviennent nettement plus lents.

Comparaison de la compression

Type de contenu gzip niveau 5 Brotli niveau 4 Gagnant
HTML 72 % 78 % Brotli
CSS 80 % 85 % Brotli
JavaScript 75 % 82 % Brotli
JSON 78 % 83 % Brotli

Les ratios représentent les octets économisés par rapport à l'original. Brotli l'emporte systématiquement de 5 à 8 points de pourcentage.

Les deux modules peuvent fonctionner simultanément. Nginx sert du Brotli aux clients qui annoncent Accept-Encoding: br et retombe sur gzip pour les autres.

Comment optimiser les performances TLS et HTTP/2 dans Nginx ?

Le TLS ajoute de la latence via les handshakes et l'échange de clés. Le cache de session, l'OCSP stapling et TLS 1.3 minimisent ce surcoût. HTTP/2 multiplexe les requêtes sur une seule connexion, éliminant le head-of-line blocking au niveau HTTP.

HTTP/2

Depuis Nginx 1.25.1, le paramètre http2 sur la directive listen est déprécié. Utilisez la directive http2 à la place :

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;

    #...
}

Performances TLS

http {
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;

    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets off;

    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;
    resolver 127.0.0.53 valid=300s;
    resolver_timeout 5s;
}

ssl_session_cache shared:SSL:10m stocke les paramètres de session TLS dans une zone de mémoire partagée de 10 Mo. Un mégaoctet contient environ 4 000 sessions. Les clients qui reviennent sautent le handshake TLS complet et reprennent avec une opération bien moins coûteuse.

ssl_session_tickets off est le défaut le plus sûr. Les tickets de session utilisent une clé symétrique qui, si elle est compromise, déchiffre toutes les sessions passées (pas de forward secrecy). Si vous avez besoin de tickets pour une architecture multi-serveurs, renouvelez les clés fréquemment.

ssl_stapling on fait récupérer et mettre en cache par Nginx la réponse OCSP de votre CA, puis l'inclut dans le handshake TLS. Le client n'a pas besoin de contacter la CA séparément. Cela économise 100 à 300 ms sur la première connexion.

ssl_prefer_server_ciphers off est correct pour TLS 1.3, où client et serveur négocient les ciphers différemment. Pour la compatibilité TLS 1.2, les ciphers sélectionnés comptent encore, mais les suites de chiffrement TLS 1.3 sont toutes solides.

Pour la configuration TLS complète avec Let's Encrypt, voir le guide TLS et Let's Encrypt pour Nginx.

Quels paramètres kernel Linux améliorent les performances de Nginx ?

Quatre paramètres kernel limitent la capacité de Nginx à gérer des volumes élevés de connexions. Les valeurs par défaut sont conservatrices pour un serveur généraliste. Les ajuster supprime les goulots d'étranglement au niveau de l'OS.

Paramètre Par défaut Recommandé Pourquoi
net.core.somaxconn 4096 65535 File d'attente maximale du listen backlog. Des valeurs basses causent des pertes de connexion en cas de pics.
fs.file-max ~100000 500000 Limite de descripteurs de fichiers à l'échelle du système. Chaque connexion est un descripteur de fichier.
net.ipv4.tcp_tw_reuse 0 1 Réutilise les sockets en TIME_WAIT pour de nouvelles connexions. Accélère le recyclage des connexions.
net.ipv4.tcp_fastopen 0 3 Active TCP Fast Open pour le client et le serveur. Économise un aller-retour sur les nouvelles connexions.
net.ipv4.ip_local_port_range 32768 60999 1024 65535 Étend la plage de ports éphémères pour les connexions sortantes (proxy/upstream).
net.core.netdev_max_backlog 1000 16384 Longueur de la file d'attente des paquets entrants quand l'interface reçoit plus vite que le kernel ne traite.

Appliquez à chaud sans redémarrage :

sysctl -w net.core.somaxconn=65535
sysctl -w fs.file-max=500000
sysctl -w net.ipv4.tcp_tw_reuse=1
sysctl -w net.ipv4.tcp_fastopen=3
sysctl -w net.ipv4.ip_local_port_range="1024 65535"
sysctl -w net.core.netdev_max_backlog=16384

Rendez-les persistants après redémarrage :

cat > /etc/sysctl.d/99-nginx-tuning.conf << 'EOF'
net.core.somaxconn = 65535
fs.file-max = 500000
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fastopen = 3
net.ipv4.ip_local_port_range = 1024 65535
net.core.netdev_max_backlog = 16384
EOF

sysctl -p /etc/sysctl.d/99-nginx-tuning.conf

net.core.somaxconn = 65535
fs.file-max = 500000
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fastopen = 3
net.ipv4.ip_local_port_range = 1024 65535
net.core.netdev_max_backlog = 16384

Augmentez aussi la limite de descripteurs de fichiers par processus pour l'unité systemd de Nginx. Créez un override :

mkdir -p /etc/systemd/system/nginx.service.d
cat > /etc/systemd/system/nginx.service.d/limits.conf << 'EOF'
[Service]
LimitNOFILE=65535
EOF

systemctl daemon-reload
systemctl restart nginx

cat /proc/$(pgrep -f 'nginx: master')/limits | grep "open files"

Max open files            65535                65535                files

Comment optimiser les performances des logs d'accès ?

Écrire une ligne de log pour chaque requête consomme des I/O disque. Sur les serveurs à fort trafic, la journalisation des accès peut devenir un goulot d'étranglement. La journalisation bufferisée écrit sur disque par lots.

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

buffer=64k accumule les entrées de log dans un tampon mémoire de 64 Ko. flush=5s écrit le tampon sur disque au moins toutes les 5 secondes, même s'il n'est pas plein. On échange quelques secondes de délai sur les logs contre beaucoup moins d'I/O disque.

Si vous n'avez pas besoin des logs d'accès pour les assets statiques (images, CSS, JS), désactivez-les par location comme montré dans la section cache ci-dessus.

Quel gain apporte un Nginx optimisé ?

Relancez le même benchmark wrk après avoir appliqué tous les changements. Testez depuis la même machine, avec les mêmes paramètres :

wrk -t4 -c200 -d30s https://your-server.example.com/

Running 30s test @ https://your-server.example.com/
  4 threads and 200 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     5.21ms    2.34ms  42.56ms   81.23%
    Req/Sec     9.78k   478.12    11.42k    68.75%
  1171200 requests in 30.02s, 4.56GB read
Requests/sec:  39013.66
Transfer/sec:    155.61MB

Avant vs. après

Métrique Avant Après Évolution
Requests/sec 16 442 39 014 +137 %
Latence moyenne 12,34 ms 5,21 ms -58 %
Latence max 89,12 ms 42,56 ms -52 %
Transfer/sec 65,52 Mo 155,61 Mo +137 %

Ces chiffres proviennent d'un VPS Virtua Cloud 4 vCPU, 8 Go de RAM sous Debian 12 avec Nginx mainline, servant une page HTML statique avec des assets CSS et JavaScript. Vos résultats varieront selon la charge, les conditions réseau et la présence ou non d'un proxy vers un backend.

Les gains les plus importants viennent des sysctl kernel (supprime les goulots de l'OS), du tuning workers/connexions (utilise tout le CPU disponible) et de la compression (réduit les octets sur le réseau). Le cache de session TLS et HTTP/2 ont un effet plus petit mais mesurable, surtout sur la latence de première connexion.

Configuration optimisée complète

Fichier /etc/nginx/nginx.conf complet avec tous les réglages appliqués :

user www-data;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

worker_processes auto;
worker_cpu_affinity auto;
worker_rlimit_nofile 8192;

events {
    worker_connections 4096;
    use epoll;
    multi_accept on;
}

http {
    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    # Optimisation TCP
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;

    # Keepalive
    keepalive_timeout 65;
    keepalive_requests 1000;

    # Tampons
    proxy_buffer_size 16k;
    proxy_buffers 4 32k;
    proxy_busy_buffers_size 64k;
    client_body_buffer_size 16k;
    client_header_buffer_size 1k;
    large_client_header_buffers 4 8k;

    # Cache de fichiers
    open_file_cache max=10000 inactive=30s;
    open_file_cache_valid 60s;
    open_file_cache_min_uses 2;
    open_file_cache_errors on;

    # Gzip
    gzip on;
    gzip_comp_level 5;
    gzip_min_length 256;
    gzip_vary on;
    gzip_proxied any;
    gzip_types
        text/plain
        text/css
        text/javascript
        application/javascript
        application/json
        application/xml
        application/xml+rss
        image/svg+xml;

    # Brotli (si module installé)
    # brotli on;
    # brotli_comp_level 4;
    # brotli_static on;
    # brotli_types text/plain text/css text/javascript
    #     application/javascript application/json application/xml
    #     image/svg+xml;

    # TLS
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets off;
    ssl_stapling on;
    ssl_stapling_verify on;

    # Journalisation
    access_log /var/log/nginx/access.log combined buffer=64k flush=5s;
    error_log /var/log/nginx/error.log warn;

    # Masquer la version
    server_tokens off;

    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

server_tokens off masque la version de Nginx dans les en-têtes de réponse et les pages d'erreur. La divulgation de version aide les attaquants à cibler des vulnérabilités connues.

Quelque chose ne fonctionne pas ?

Consultez d'abord le log d'erreur :

journalctl -u nginx -f

Problèmes courants après le tuning :

  • "too many open files" dans le log d'erreur : worker_rlimit_nofile est inférieur à worker_connections, ou le LimitNOFILE de systemd n'est pas défini. Vérifiez les deux.
  • "could not build optimal types_hash" : augmentez types_hash_max_size à 4096 dans le bloc http.
  • Le module Brotli ne se charge pas : lancez nginx -V 2>&1 | grep brotli pour vérifier si le module est compilé. Si vous utilisez des modules dynamiques, vérifiez que les directives load_module sont présentes en haut de nginx.conf.
  • L'OCSP stapling ne fonctionne pas : la première requête après le démarrage de Nginx n'aura pas de réponse stapled. Testez avec openssl s_client -connect your-server:443 -status < /dev/null 2>&1 | grep -A 2 "OCSP Response". Si le résultat indique "no response sent", vérifiez que ssl_trusted_certificate pointe vers la chaîne complète et que resolver est défini.
  • wrk ne montre aucune amélioration : assurez-vous de tester depuis une machine différente. Si vous testez via internet, la latence réseau domine et masque les gains côté serveur. Testez depuis un VPS dans le même datacenter pour des chiffres précis.

Copyright 2026 Virtua.Cloud. Tous droits réservés. Ce contenu est une création originale de l'équipe Virtua.Cloud. Toute reproduction, republication ou redistribution sans autorisation écrite est interdite.

Prêt à essayer ?

Déployez votre serveur en quelques secondes. Linux, Windows ou FreeBSD.

Voir les offres VPS

Articles associés

Optimisation performances Nginx : guide complet