Nginx 静的ファイル サービスの構成と最適化の詳細な説明

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

root ディレクティブは、ファイルの検索に使用するルート ディレクトリを指定します。 要求されたファイルへのパスを取得するために、NGINX はルート ディレクティブで指定されたパスにリクエスト URI を追加します。このディレクティブは、http{}、server{}、または location{} コンテキスト内の任意のレベルに配置できます。次の例では、仮想サーバーのルート ディレクティブが定義されています。 これは、ルートを明示的に再定義するルート ディレクティブを含まないすべての location {} ブロックに適用されます。

サーバー{
  ルート /www/data;

  位置 / {
  }

  場所 /images/ {
  }

  場所 ~ \.(mp3|mp4) {
    ルート /www/media;
  }
}

ここで、NGINX はファイルシステム上の /www/data/images/ ディレクトリ内で /images/ で始まる URI のファイルを検索します。 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 パラメータを含めます。

場所 /images/ {
  自動インデックスオン;
}

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

位置 / {
  インデックス index.$geo.html index.htm index.html;
}

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

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

位置 / {
  ルート /data;
  インデックス index.html index.php;
}

場所 ~ \.php {
  fastcgi_pass ローカルホスト:8000;
  #...

}

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

いくつかのオプションを試してみる

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

サーバー{
  ルート /www/data;

  場所 /images/ {
    try_files $uri /images/default.gif;
  }
}

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

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

位置 / {
  try_files $uri $uri/ $uri.html =404;
}

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

位置 / {
  try_files $uri $uri/ @backend;
}

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

詳細については、コンテンツ キャッシュのウェビナーを視聴して、Web サイトのパフォーマンスを大幅に向上させる方法と、NGINX のキャッシュ機能についてより深く理解する方法をご確認ください。

サービスコンテンツのパフォーマンスを最適化する

読み込み速度は、あらゆるコンテンツを提供する上で重要な要素です。 NGINX 構成を少し最適化するだけで、生産性が向上し、最適なパフォーマンスを実現できます。

送信ファイルを有効にする

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

場所 /mp3 {
  ファイル送信オン;
  送信ファイル最大チャンク1m;
  #...

}

tcp_nopushを有効にする

sendfile on; ディレクティブとともに tcp_nopush ディレクティブを使用します。これにより、NGINX は sendfile() がデータ チャンクを取得した直後に、HTTP 応答ヘッダーを 1 つのパケットで送信できるようになります。

場所 /mp3 {
  ファイル送信オン;
  tcp_nopush オン;
  #...

}

tcp_nodelayを有効にする

tcp_nodelay ディレクティブを使用すると、低速ネットワークでの小さなパケットの問題を解決するために元々設計された Nagle アルゴリズムをオーバーライドできます。このアルゴリズムは、多数の小さなパケットを 1 つの大きなパケットに結合し、200 ミリ秒の遅延でパケットを送信します。現在、大きな静的ファイルを提供する場合、パケット サイズに関係なく、データを即座に送信できます。レイテンシはオンライン アプリケーション (ssh、オンライン ゲーム、オンライン トレーディングなど) にも影響します。デフォルトでは、tcp_nodelay ディレクティブはオンに設定されており、Nagle アルゴリズムは無効になっています。このディレクティブはキープアライブ接続にのみ使用されます。

場所 /mp3 {
  tcp_nodelay オン;
  キープアライブタイムアウト65;
  #...
  
}

バックログキューの最適化

重要な要素の 1 つは、NGINX が着信接続をどれだけ速く処理できるかです。一般的なルールとしては、接続が確立されると、その接続はリスニング ソケットの「listen」キューに配置されます。通常の負荷では、キューはほとんどまたはまったくありません。しかし、負荷が高い場合、キューが大幅に増加し、パフォーマンスの不均一、接続の切断、待ち時間の増加が発生する可能性があります。

バックログ キューを表示します。現在のリスニング キューを表示するには、netstat -Lan コマンドを使用します。出力は次のようになります。これは、キューに入れられた接続の最大数として設定された 128 個のうち、ポート 80 のリスニング キューに受け入れられていない接続が 10 個あることを示しています。これは正常です。

現在のリッスン キューのサイズ (qlen/incqlen/maxqlen)
ローカルアドレスを聴く     
0/0/128 *.12345      
10/0/128 *.80    
0/0/128 *.8080

一方、次のコマンドでは、受け入れられない接続数 (192) が 128 の制限を超えています。これは、Web サイトのトラフィックが多い場合によく発生します。最適なパフォーマンスを実現するには、オペレーティング システムと NGINX 構成で、NGINX が受け入れるためにキューに入れることができる接続の最大数を増やす必要があります。

現在のリッスン キューのサイズ (qlen/incqlen/maxqlen)
ローカルアドレスを聴く     
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. /etc/sysctl.conf ファイルに net.core.somaxconn = 4096 を追加します。

NGINXのチューニング

somaxconn カーネル パラメータを 512 より大きい値に設定する場合は、変更に合わせて NGINX listen ディレクティブの backlog パラメータを増やします。

サーバー{
  80を聴くバックログ=4096;
  # ...

}

© この記事は、Nginx Serving Static Content から翻訳されたもので、意味的な調整がいくつか加えられています。

以上がこの記事の全内容です。皆様の勉強のお役に立てれば幸いです。また、123WORDPRESS.COM を応援していただければ幸いです。