Configuration du tampon d'Nginx Le tampon de requête joue un rôle crucial dans le traitement des requêtes par Nginx. Lorsqu'une requête est reçue, elle est écrite dans un tampon qui devient une variable pour Nginx, comme $request_body. Si le tampon est plus petit que la taille de la requête, les données supplémentaires sont écrites sur le disque, ce qui entraîne des opérations d'E/S. Nginx fournit plusieurs directives pour modifier la configuration du tampon de requête.

Directive client_body_buffer_sizeCette directive définit la taille du tampon pour le corps de la requête. Si le corps dépasse cette taille, l'intégralité ou une partie du corps est écrite dans un fichier temporaire. Si Nginx est configuré pour utiliser uniquement un tampon de fichier et pas un tampon en mémoire, alors cette directive n'est pas prise en compte. La valeur par défaut est de 8K sur les systèmes 32 bits et 16K sur les systèmes 64 bits. Elle peut être définie à l'échelle de l'http, du server et du location, comme suit :

server {
        client_body_buffer_size 8k;
}

Directive client_max_body_sizeCette directive définit la taille maximale du corps de la requête que Nginx peut traiter. Si une requête est plus grande que cette taille, Nginx répond avec une erreur HTTP 413 (Entity Too Large). Cela est particulièrement important si votre serveur web offre des téléchargements de fichiers volumineux. La valeur par défaut est de 1M. Elle peut également être définie à l'échelle de l'http, du server et du location, comme suit :

server {
   client_max_body_size 2m;
}

Directive client_body_in_file_onlyLorsqu'elle est activée, cette directive désactive le tampon de requête de Nginx et stocke le corps de la requête dans un fichier temporaire. Elle peut avoir trois valeurs :

• off : interdit l'écriture de fichiers
• clean : le corps de la requête est écrit dans un fichier, qui est supprimé après le traitement de la requête
• on : le corps de la requête est écrit dans un fichier, mais celui-ci n'est pas supprimé après le traitement de la requête

La valeur par défaut est off. On peut la définir comme suit :

http {
    client_body_in_file_only clean;
}

Cette directive est utile pour le débogage des erreurs, mais ne doit pas être utilisée en production.

Directive client_body_in_single_bufferCette directive permet à Nginx de stocker tous les corps de la requête dans un seul tampon. Sa valeur par défaut est off. Activer cette option peut optimiser la performance de lecture de la variable $request_body. Elle peut être définie à l'échelle de l'http, du server et du location, comme suit :

server {
    client_body_in_single_buffer on;
}

Directive client_body_temp_pathCette directive spécifie le chemin du répertoire temporaire où seront stockés les corps de la requête. Il peut également définir la hiérarchie des répertoires. Par défaut, Nginx crée les fichiers temporaire dans le sous-répertoire client_body_temp de son installation. Cette directive peut être définie à l'échelle de l'http, du server et du location, comme suit :

server {
     client_body_temp_path temp_files 1 2;
}

Directive client_header_buffer_sizeCette directive est similaire à client_body_buffer_size. Elle alloue un tampon pour le header de la requête. La valeur par défaut est de 1K et peut être définie à l'échelle de l'http et du server, comme suit :

http {
  client_header_buffer_size 1m;
}

Directive large_client_header_buffersCette directive spécifie le nombre et la taille des tampons pour le header de la requête. Elle est utilisée uniquement lorsque le tampon par défaut n'est pas suffisant. Les tampons sont libérés quand la requête est terminée ou quand la connexion entre en état keep-alive. Elle peut être définie à l'échelle de l'http et du server, comme suit :

http {
   large_client_header_buffers 4 8k;
}

Si la URI de la requête dépasse la taille d'un seul tampon, Nginx retourne une erreur HTTP 414 (URI Too Long). Si tout header de la requête dépasse la taille d'un seul tampon, Nginx retourne une erreur HTTP 400 (Bad Request).

Délais de Nginx (Timeout) Chaque requête traitée par Nginx a ses propres délais associés. Une bonne optimisation de ces délais améliore considérablement la performance d'Nginx. Après un délai, les ressources système sont libérées pour traiter d'autres requêtes. Nous examinerons maintenant les différentes directives de délais fournies par Nginx.

Directive keepaliveL'HTTP est un protocole sans état, basé sur des requêtes et réponses individuelles. Le client ouvre un port TCP vers le serveur et envoie une requête. Le serveur répond, puis ferme la connexion pour libérer les ressources du serveur. Si le client envoie plusieurs requêtes, chaque requête nécessite sa propre connexion TCP, ce qui rend ce processus inefficace, surtout lorsqu'une page Web contient beaucoup de contenu. L'HTTP propose un mode keepalive, qui permet au serveur web de maintenir les connexions TCP ouvertes après avoir traité une requête. Si le client envoie une autre requête, il peut réutiliser ces connexions ouvertes plutôt qu'en établissant de nouvelles. Quand le client décide d'arrêter d'utiliser ces connexions ouvertes, ou si le serveur détecte qu'elles ne sont pas actives pendant un certain temps (timeout), elles sont fermées. Les navigateurs généralement ouvrent plusieurs connexions keepalive.

Directive keepalive_timeoutCette directive définit le délai avant lequel une connexion keepalive est fermée, par défaut à 65 secondes. Si elle est définie à 0, les connexions keepalive sont désactivées. Elle peut être définie à l'échelle de l'http, du server et du location, comme suit :

http {
   keepalive_timeout 20s;
}

Il existe également un deuxième paramètre optionnel pour cette directive, comme ceci :

http {
    keepalive_timeout 20s 18s;
}

Le deuxième paramètre 18s est inclus dans le header de réponse :

curl -I http://www.example.com

........

Connection: keep-alive

Keep-Alive: timeout=18

.....

Directive keepalive_requestsCette directive fixe le nombre maximal de requêtes pouvant être effectuées sur une seule connexion keepalive. Si le nombre de requêtes atteint cette limite, le serveur ferme la connexion keepalive. La valeur par défaut est de 100 et peut être définie à l'échelle de l'http, du server et du location, comme suit :

http {
   keepalive_requests 20;
}

Directive keepalive_disabledCette directive peut désactiver les connexions keepalive pour certains navigateurs spécifiques. La valeur par défaut est msie6 et peut être définie à l'échelle de l'http, du server et du location, comme suit :

http {
   keepalive_disabled msie6 safari;
}

Directive send_timeoutCette directive définit le délai avant lequel Nginx arrête d'envoyer des données à un client. La valeur par défaut est de 60 secondes et peut être définie à l'échelle de l'http, du server et du location, comme suit :

server {
   send_timeout 30s;
}

Directive client_body_timeoutCette directive définit le délai avant lequel un client doit envoyer le corps de sa requête à Nginx. Si le client ne fait rien pendant ce délai, Nginx renvoie une erreur HTTP 408 (Request Timed Out). La valeur par défaut est de 60 secondes et peut être définie à l'échelle de l'http, du server et du location, comme suit :

server {
    client_body_timeout 30s;
}

Directive client_header_timeoutCette directive définit le délai avant lequel un client doit envoyer entièrement le header de sa requête à Nginx. Si le client ne fait rien pendant ce délai, Nginx renvoie une erreur HTTP 408 (Request Timed Out). La valeur par défaut est de 60 secondes et peut être définie à l'échelle de l'http et du server, comme suit :

server {
   client_header_timeout 30s;
}

Compression de Nginx (Compression) La compression réduit la taille des paquets de données envoyés par le serveur, ce qui accélère le chargement des pages Web.

Module ngx_http_gzip_moduleLa compression gzip d'Nginx dépend de ce module. Le serveur compresser d'abord les données, puis les envoie au client. La compression est particulièrement efficace pour le contenu texte, tandis que gzip n'affecte pas vraiment le contenu non-compressible comme JPEG, GIF, MP3. De plus, une compression trop élevée consomme plus de CPU. Le module ngx_http_gzip_module fournit les directives suivantes pour configurer la compression gzip.

Directive gzipCette directive active la fonctionnalité de compression gzip d'Nginx. La valeur par défaut est on et peut être définie à l'échelle de l'http, du server et du location, ainsi que dans les instructions if, comme suit :

http {
    gzip on;
}

Directive gzip_comp_levelCette directive définit le niveau de compression gzip. Le niveau peut varier de 1 à 9. Un niveau élevé de compression n'améliore pas grandement les performances car cela demande plus de temps de processeur. La valeur par défaut est de 1, dont 1 à 3 sont considérés comme bons car ils équilibrent bien la taille finale des données compressées et le temps de processeur nécessaire. Elle peut être définie à l'échelle de l'http, du server et du location, comme suit :

http {
    gzip_comp_level 2;
}

Directive gzip_min_lengthCette directive indique la longueur minimale des données à compresser. Seulement les données dont la longueur est supérieure ou égale à cette longueur seront compressées. La longueur est obtenue à partir de Content-Length. La valeur par défaut est de 20 octets et peut être définie à l'échelle de l'http, du server et du location, comme suit :

http {
   gzip_min_length 1000;
}

Directive gzip_typesCette directive spécifie les types de réponse qui peuvent être compressés. La valeur par défaut est text/html et peut être définie à l'échelle de l'http, du server et du location, comme suit :

http {
   gzip_types text/html text/css text/plain;
}

Les types text/html sont toujours compressés. text/html, text/css et text/plain sont des types MIME.

Directive gzip_http_versionCette directive spécifie une version HTTP. Seulement si la version HTTP de la requête est supérieure ou égale à celle définie, Nginx compressera les données. La valeur par défaut est de 1.1 et peut être définie à l'échelle de l'http, du server et du location, comme suit :

http {
   gzip_http_version 1.1;
}

Directive gzip_varyCette directive ajoute une ligne Vary: Accept-Encoding au header de la réponse. La valeur par défaut est off et peut être définie à l'échelle de l'http, du server et du location, comme suit :

http {
   gzip_vary on;
}

Directive gzip_disableModule ngx_http_gzip_static_moduleDirective gzip_staticCette directive permet à Nginx d'envoyer un fichier .gz compressé. La valeur par défaut est off. Si gzip_static est défini à on, Nginx vérifie d'abord si le client supporte les fichiers .gz. Si oui, il envoie le fichier .gz, sinon il envoie le fichier normal. Il peut également être défini à always, ce qui signifie que Nginx enverra toujours le fichier .gz (si il existe) sans vérifier si le client supporte la compression. gzip_static vérifie également les valeurs de gzip_http_version, gzip_proxied et gzip_disable pour déterminer si le client supporte la compression. Ces valeurs peuvent être définies à l'échelle de l'http, du server et du location, comme suit :

server {
    gzip_static always;
}

Module ngx_http_gunzip_moduleCe module permet à Nginx d'envoyer un fichier décompressé aux clients qui ne supportent pas gzip, souvent utilisé en conjonction avec le module ngx_http_gzip_static_module. Celui-ci permet à Nginx d'envoyer un fichier déjà compressé, tandis que ce dernier peut décompresser le fichier pour l'envoyer aux clients qui ne supportent pas la compression. Ce module n'est pas activé par défaut et peut être activé à la compilation de Nginx avec l'option –with-http_gunzip_module. Voici la directive fournie par ce module :

Directive gunzipCette directive permet de décompresser les fichiers .gz. La valeur par défaut est off et peut être définie à l'échelle de l'http, du server et du location, comme suit :

location / {
     gzip_static always;
     gunzip on;
}

Journaux de Nginx Les journaux sont une double tranchée. D'un côté, ils offrent beaucoup d'informations utiles ; de l'autre, ils entraînent des coûts en termes de calcul. Si Nginx produit mille et une lignes de journal, cela peut affecter les performances. Nous examinerons maintenant quelques directives pour optimiser les journaux.

Directive access_logCette directive configure les journaux générés par Nginx pour toutes les requêtes traitées. Elle prend plusieurs paramètres pour spécifier le chemin du journal, le format du modèle, le tampon, etc. syslog peut transmettre les journaux à un serveur de journaux sans les écrire dans un fichier. Si la valeur de access_log est définie à off, Nginx ne générera aucun journal. Le chemin par défaut du fichier de journal d'accès est /var/log/nginx/access.log.

http {
    access_log /var/log/nginx/access.log;
}

Directive error_logNginx active par défaut les journaux d'erreurs. L'erreur_log peut être définie à l'échelle de l'http, du server et du location. Elle prend deux paramètres : le chemin du fichier de journal d'erreur et le niveau de gravité. Les niveaux de gravité possibles sont debug, info, notice, warn, error, crit, alert et emerg.

http {
       error_log /var/log/nginx/error.log crit;
}

Synthèse Voici une configuration globale qui combine toutes les directives discutées précédemment.

http {
      ######
      # Configuration du tampon
      ######
      client_body_buffer_size 15k;
      client_max_body_size 8m;

      ####
      # Configuration des délais
      ####
      keepalive_timeout 20;
      client_body_timeout 15;
      client_header_timeout 15;
      send_timeout 10;

      ######
      # Configuration de la compression
      ######
      gzip on;
      gzip_comp_level 2;
      gzip_min_length 1000;
      gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;

     #####
     # Configuration des journaux
     #####
     access_log off;
     log_not_found off;
     error_log logs/error.log crit;
}