Nginx静的ファイルサービスの構成と最適化

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

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

server {
    root /www/data;

    location / {
    }

    location /images/ {
    }

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

ここで、NGINX for /images/URIは、ファイルシステムによる/www/ data/images/ディレクトリ内のファイルの検索の最初になります。拡張子付き.mp3または.mp4末尾のURIの場合、NGINXは/www/media/ブロックマッチングの位置で定義されているファイルディレクトリを検索します。

リクエストが/で終わっている場合、NGINXはそれをディレクトリのリクエストとして扱い、ディレクトリでインデックスファイルを見つけようとします。indexこのディレクティブは、インデックスファイルの名前を定義します（デフォルト値はindex.htmlです）。例を続けると、リクエストURIがの場合/images/some/path/、NGINXはファイル/www/data/images/some/path/index.html（存在する場合）を返します。そうでない場合、NGINXはデフォルトでHTTP 404エラー（見つかりません）を返します。autoindexパラメータに含まれる手順で、自動的に生成されたディレクトリリストを返すようにNGINXを構成するには：

location /images/ {
    autoindex on;
}

あなたはできるindexディレクティブ複数のファイル名を一覧表示します。NGINXは指定された順序でファイルを検索し、見つかった最初のファイルを返します。

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

ここで使用される$geo変数は、geoカスタム変数命令セットによって定義されます。変数の値は、クライアントのIPアドレスによって異なります。

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

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

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

}

ここで、要求がURIであり/path/、及び/data/path/index.html存在なしで/data/path/index.php存在するが、内部リダイレクトする/path/index.php第2の位置にマッピングされます。その結果、リクエストはプロキシされます。

いくつかのオプションを試してください

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

server {
    root /www/data;

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

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

最後のパラメーターは、状況コード（直接等号を直接使用）またはロケーション名にすることもできます。次の例では、try_filesすべての指示が既存のファイルまたはディレクトリに解決されないパラメーターである場合、エラーが404で返されます。

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

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

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

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

詳細については、コンテンツキャッシングウェブセミナーを視聴して、ウェブサイトのパフォーマンスを大幅に改善する方法と、NGINXのキャッシング機能について詳しく学んでください。

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

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

有効にする sendfile

デフォルトでは、NGINXはファイル転送自体を処理し、送信する前にファイルをバッファにコピーします。enable sendfileコマンドは、データをバッファーにコピーするステップを排除し、データをファイル記述子から別の記述子に直接コピーできるようにします。または、クイックコネクタが完全に占有されたワークプロセスを防止するために、コールで送信されるデータ量がsendfile_max_chunk1つsendfile()（この例では1 MB）の命令制限を使用できます。

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

}

有効にする tcp_nopush

tcp_nopush指示sendfile on;命令で使用します。これにより、NGINX sendfile()はデータブロックを取得した後、データパケットでHTTP応答ヘッダーをすぐに送信できます。

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

}

有効にする tcp_nodelay

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

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

}

バックログキューを最適化する

重要な要素の1つは、NGINXが着信接続を処理する速度です。一般的なルールは、接続を確立するときに、リスニングソケットの「リッスン」キューに入れることです。通常の負荷では、キューが小さいか、キューがまったくありません。ただし、高負荷の場合、キューは急激に大きくなり、パフォーマンスが不均一になり、接続が中断され、レイテンシが増加します。

バックログキューを表示

コマンド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;
    # ...

}