Comment configurer et optimiser le service de fichiers statiques Nginx

Répertoire racine et fichiers d'index

La directive racine spécifie le répertoire racine qui sera utilisé pour rechercher les fichiers. Pour obtenir le chemin d'accès au fichier demandé, nginx ajoute l'URI de la demande au chemin spécifié par la directive racine. Cette directive peut être placée à n'importe quel niveau dans le contexte http {} , server {} ou location {}. Dans l'exemple suivant, la directive racine est définie pour le serveur virtuel. Cela fonctionne pour tous les blocs location {} qui ne contiennent pas de directive racine pour redéfinir explicitement la racine :

server {
  root /www/data;

  location / {
  }

  location /images/ {
  }

  location ~ \.(mp3|mp4) {
    root /www/media;
  }
}

Ici, nginx pour les uris commençant par /images/ recherchera dans le répertoire /www/ data/images/ du système de fichiers Documents correspondants. Si l'uri se termine par une extension .mp3 ou .mp4, nginx recherche le fichier dans le répertoire /www/media/ car il est défini dans un bloc d'emplacement correspondant.

Si la requête se termine par /, nginx la traite comme une requête au répertoire et essaie de trouver le fichier d'index dans le répertoire. La directive index définit le nom du fichier d'index (la valeur par défaut est index.html). Pour continuer l'exemple, si l'uri de la requête est /images/some/path/ , nginx renvoie le fichier /www/data/images/some/path/index.html s'il existe. Sinon, nginx renvoie une erreur http 404 (introuvable) par défaut. Pour configurer nginx pour qu'il renvoie une liste de répertoires générée automatiquement, incluez le paramètre on dans la directive autoindex :

location /images/ {
  autoindex on;
}

Vous pouvez répertorier plusieurs noms de fichiers dans la directive index. nginx recherche les fichiers dans l'ordre spécifié et renvoie le premier fichier trouvé.

location / {
  index index.$geo.html index.htm index.html;
}

La variable $geo utilisée ici est une variable personnalisée définie via la directive geo. La valeur de la variable dépend de l'adresse IP du client.

Pour renvoyer le fichier d'index, nginx vérifie s'il existe puis effectue une redirection interne vers le nouvel uri obtenu en ajoutant le nom du fichier d'index à l'uri de base. Les redirections internes entraînent une nouvelle recherche de l'emplacement et peuvent aboutir à un autre emplacement, comme le montre l'exemple suivant :

location / {
  root /data;
  index index.html index.php;
}

location ~ \.php {
  fastcgi_pass localhost:8000;
  #...

}

Ici, si l'URI dans la requête est /path/ et /data/path/index.html le fait n'existe pas Mais /data/path/index.php existe, alors la redirection interne vers /path/index.php sera mappée vers le deuxième emplacement. En conséquence, la demande est proxy.

Essayez quelques options

La directive try_files peut être utilisée pour vérifier si un fichier ou un répertoire spécifié existe ; nginx effectue une redirection interne et renvoie le code d'état spécifié sinon. Par exemple, pour vérifier si le fichier correspondant à l'uri de la requête existe, utilisez la directive try_files et la variable $uri comme suit :

server {
  root /www/data;

  location /images/ {
    try_files $uri /images/default.gif;
  }
}

Le fichier est spécifié comme un uri, en utilisant la racine définie dans l'emplacement ou le contexte actuel du serveur virtuel ou instructions d'alias pour le traitement. Dans ce cas, si le fichier correspondant à l'uri d'origine n'existe pas, nginx redirigera en interne vers l'uri spécifié par le dernier paramètre et renverra /www/data/images/default.gif .

Le dernier paramètre peut également être un code d'état (commençant directement par un signe égal) ou un nom de lieu. Dans l'exemple suivant, si aucun des arguments de la directive try_files ne correspond à un fichier ou un répertoire existant, une erreur 404 est renvoyée.

location / {
  try_files $uri $uri/ $uri.html =404;
}

Dans l'exemple suivant, si ni l'URI d'origine ni l'URI avec une barre oblique finale ajoutée ne sont résolus en un fichier ou un répertoire existant, la demande est redirigée vers l'emplacement spécifié et transmise au serveur proxy.

location / {
  try_files $uri $uri/ @backend;
}

location @backend {
  proxy_pass http://backend.example.com;
}

Optimisez les performances du contenu diffusé

La vitesse de chargement est un facteur clé dans la diffusion de tout contenu. Des optimisations mineures de votre configuration nginx peuvent augmenter la productivité et aider à atteindre des performances optimales.

Activer sendfile

Par défaut, nginx gère lui-même le transfert de fichier et copie le fichier dans un tampon avant l'envoi. L'activation de la directive sendfile élimine l'étape de copie des données dans un tampon et permet aux données d'être copiées directement d'un descripteur de fichier à un autre. Alternativement, pour éviter qu'une connexion rapide n'occupe complètement le processus de travail, vous pouvez utiliser la directive sendfile_max_chunk pour limiter la quantité de données transférées en un seul appel sendfile() (dans ce cas 1 Mo) :

location /mp3 {
  sendfile      on;
  sendfile_max_chunk 1m;
  #...

}

Enable tcp_nopush

Combinez la directive tcp_nopush avec la directive Used avec la directive sendfile on ; Cela permet à nginx d'envoyer des en-têtes de réponse http dans un paquet juste après que sendfile() ait obtenu le morceau de données.

location /mp3 {
  sendfile  on;
  tcp_nopush on;
  #...

}

Activer tcp_nodelay

La directive tcp_nodelay permet de remplacer l'algorithme de Nagle, qui a été initialement conçu pour résoudre le problème des petits paquets dans les réseaux lents. L'algorithme combine de nombreux petits paquets en un seul paquet plus gros et envoie le paquet avec un délai de 200 millisecondes. Aujourd'hui, lors du traitement de fichiers statiques volumineux, les données peuvent être envoyées instantanément, quelle que soit la taille du paquet. La latence affecte également les applications en ligne (ssh, jeux en ligne, transactions en ligne, etc.). Par défaut, la directive tcp_nodelay est activée, ce qui signifie que l'algorithme de Nagle est désactivé. Cette directive n'est utilisée que pour les connexions keepalive :

location /mp3 {
  tcp_nodelay    on;
  keepalive_timeout 65;
  #...
  
}

Optimize backlog queue

其中一个重要因素是 nginx 可以多快地处理传入连接。一般规则是在建立连接时，将其放入侦听套接字的 "listen" (监听)队列中。在正常负载下，队列很小或根本没有队列。但是在高负载下，队列会急剧增长，导致性能不均匀，连接中断，延迟增加。

显示积压队列使用命令 netstat -lan 来显示当前监听队列。输出可能如下所示，它显示在端口 80上的监听队列中，有 10 个未接受的连接，这些连接针对配置的最多 128 个排队连接。这种情况很正常。

current listen queue sizes (qlen/incqlen/maxqlen)
listen     local address     
0/0/128    *.12345      
10/0/128    *.80    
0/0/128    *.8080

相反，在以下命令中，未接受的连接数（192）超过了 128 的限制。当网站流量很大时，这种情况很常见。要获得最佳性能，需要在操作系统和 nginx 配置中增加可以排队等待 nginx 接受的最大连接数。

current listen queue sizes (qlen/incqlen/maxqlen)
listen     local address     
0/0/128    *.12345      
192/0/128    *.80    
0/0/128    *.8080

调整操作系统

将 net.core.somaxconn 内核参数的值从其默认值（128）增加到足以容纳大量流量的值。在这个例子中，它增加到 4096。

• freebsd 的命令为 sudo sysctl kern.ipc.somaxconn=4096

• linux 的命令为 1. sudo sysctl -w net.core.somaxconn=4096 2. 将 net.core.somaxconn = 4096 加入到 /etc/sysctl.conf 文件中。

调整 nginx

如果将 somaxconn 内核参数设置为大于 512 的值，请将 backlog 参数增加在 nginx listen 指令以匹配修改：

server {
  listen 80 backlog=4096;
  # ...

}

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!