Nginx 静的ファイル サービスを構成および最適化する方法

ルート ディレクトリとインデックス ファイル

ルート ディレクティブは、ファイルの検索に使用されるルート ディレクトリを指定します。要求されたファイルへのパスを取得するために、nginx は root ディレクティブで指定されたパスに要求 URI を追加します。このディレクティブは、 http {} 、server {} または location {} コンテキスト内の任意のレベルに配置できます。次の例では、仮想サーバーに対して root ディレクティブが定義されています。これは、ルート ディレクティブを含まないすべての location {} ブロックで動作し、ルートを明示的に再定義します。 / ディレクトリ内の対応するファイル。 URI が .mp3 または .mp4 拡張子で終わる場合、そのファイルは一致するロケーション ブロックで定義されているため、nginx は /www/media/ ディレクトリでファイルを検索します。

リクエストが / で終わる場合、nginx はそれをディレクトリへのリクエストとして扱い、ディレクトリ内のインデックス ファイルを検索しようとします。 Index ディレクティブは、インデックス ファイルの名前を定義します (デフォルトは、index.html)。例を続けると、リクエスト URI が /images/some/path/ の場合、nginx はファイル /www/data/images/some/path/index.html (存在する場合) を返します。そうでない場合、nginx はデフォルトで http 404 エラー (見つからない) を返します。自動的に生成されたディレクトリ リストを返すように nginx を設定するには、autoindex ディレクティブに on パラメータを含めます。

server {
  root /www/data;

  location / {
  }

  location /images/ {
  }

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

index ディレクティブには複数のファイル名をリストできます。 nginx は指定された順序でファイルを検索し、最初に見つかったファイルを返します。

location /images/ {
  autoindex on;
}

ここで使用される $geo 変数は、geo ディレクティブを通じて設定されたカスタム変数です。変数の値はクライアントの IP アドレスによって異なります。

インデックス ファイルを返すために、nginx はそのファイルが存在するかどうかを確認し、ベース URI にインデックス ファイルの名前を追加することによって取得された新しい URI への内部リダイレクトを実行します。次の例に示すように、内部リダイレクトによって場所が新たに検索され、別の場所に到達する可能性があります。

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

ここでは、リクエストの URI が /path/ および /data/path/index の場合です。 .html は存在しないが、/data/path/index.php は存在する場合、/path/index.php への内部リダイレクトは 2 番目の場所にマップされます。その結果、リクエストはプロキシ処理されます。

try_files ディレクティブを使用して、指定されたファイルまたはディレクトリが存在するかどうかを確認できます。nginx は内部でリダイレクトし、存在しない場合は戻ります。指定されたステータスコード。たとえば、リクエスト URI に対応するファイルが存在するかどうかを確認するには、次のように try_files ディレクティブと $uri 変数を使用します。

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

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

}

ファイルは、現在の場所のコンテキストを使用して URI として指定されます。仮想サーバーに設定されたルートまたはエイリアス ディレクティブが処理されます。この場合、元の URI に対応するファイルが存在しない場合、nginx は最後のパラメータで指定された URI に内部的にリダイレクトし、 /www/data/images/default.gif を返します。

最後のパラメータは、ステータス コード (直接等号で始まる) または場所名にすることもできます。次の例では、try_files ディレクティブの引数がいずれも既存のファイルまたはディレクトリに解決されない場合、404 エラーが返されます。

server {
  root /www/data;

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

次の例では、元の URI も末尾にスラッシュが追加された URI も既存のファイルまたはディレクトリに解決されない場合、リクエストは指定された場所にリダイレクトされ、プロキシ サーバーに渡されます。

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

読み込み速度は、コンテンツを提供する際の重要な要素です。 nginx 構成を少し最適化すると、生産性が向上し、最適なパフォーマンスを達成できるようになります。

デフォルトでは、nginx はファイル転送自体を処理し、送信前にファイルをバッファにコピーします。 sendfile ディレクティブを有効にすると、データをバッファにコピーする手順が不要になり、あるファイル記述子から別のファイル記述子にデータを直接コピーできるようになります。あるいは、高速接続がワーカー プロセスを完全に占有することを防ぐために、sendfile_max_chunk ディレクティブを使用して、1 回の sendfile() 呼び出しで転送されるデータ量 (この場合は 1 MB) を制限できます。 ##enable tcp_nopush

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

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

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

}

其中一个重要因素是 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;
  # ...

}

以上がNginx 静的ファイル サービスを構成および最適化する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。