Nginx構成を最適化する方法

投稿日: 2022-04-20 2022-04-20
タグ: nginx, Server Optimization

序章

Nginx

Nginxは、ときどき圧倒されるApache2に代わる高速で軽量な代替手段です。ただし、Nginxは、他の種類のサーバーやソフトウェアと同様に、最適なパフォーマンスを実現するために調整する必要があります。

要件

初期セットアップが完了したの新しいDebian7ドロップレット。
ドロップレットには、新しくインストールおよび構成されたNginxサーバーも実行されている必要があります。 Debian LEMP Stackチュートリアルを試してみてください。もう少し基本的なことについては、 Debian NginxServerBlocksチュートリアルを試してください。
Linuxの基本をよく理解している。

ワーカープロセスとワーカー接続

調整する必要がある最初の2つの変数は、ワーカープロセスとワーカー接続です。各設定にジャンプする前に、これらの各ディレクティブが何を制御するかを理解する必要があります。 worker_processes ディレクティブは、Nginxの頑丈な生命の背骨です。このディレクティブは、仮想サーバーが適切なIPとポートにバインドされた後にスポーンするワーカーの数を仮想サーバーに通知する役割を果たします。コアごとに1つのワーカープロセスを実行するのが一般的な方法です。これを超えるものはシステムに害を及ぼすことはありませんが、通常はアイドル状態のプロセスがうそをついたままになります。

worker_processes を設定する必要がある数を把握するには、セットアップにあるコアの数を確認するだけです。 DigitalOcean 512MBセットアップを使用している場合は、おそらく1つのコアになります。より大きなセットアップにすばやくサイズ変更することになった場合は、コアを再度確認し、それに応じてこの数を調整する必要があります。これは、cpuinfoをgrepすることで実現できます。

grep processor /proc/cpuinfo | wc -l

これが値1を返すとしましょう。それが私たちのマシンのコアの量です！

worker_connectionsコマンドは、Nginxが同時にサービスを提供できる人数をワーカープロセスに通知します。デフォルト値は768です。ただし、すべてのブラウザが通常少なくとも2つの接続/サーバーを開くことを考えると、この数は半分になる可能性があります。これが、ワーカーの接続を最大限に調整する必要がある理由です。 ulimitコマンドを発行することで、コアの制限を確認できます。

ulimit -n

小型のマシン（512MBのドロップレット）では、この数値はおそらく1024になります。これは、適切な開始数値です。

設定を更新しましょう：

sudo nano /etc/nginx/nginx.conf

worker_processes 1;
worker_connections 1024;

サービスできるクライアントの数にコアの数を掛けることができることを忘れないでください。この場合、1024クライアント/秒をサーバーできます。ただし、これはkeepalive_timeoutディレクティブによってさらに軽減されます。

バッファ

私たちが行うことができるもう1つの非常に重要な調整は、バッファーサイズです。バッファサイズが小さすぎると、Nginxは一時ファイルに書き込む必要があり、ディスクが常に読み取りと書き込みを行うようになります。決定を下す前に理解する必要のあるいくつかの指示があります。

client_body_buffer_size：これは、クライアントのバッファーサイズを処理します。つまり、Nginxに送信されるPOSTアクションを処理します。 POSTアクションは通常、フォームの送信です。

client_header_buffer_size：前のディレクティブと同様ですが、代わりにクライアントヘッダーサイズを処理します。すべての意図と目的のために、1Kは通常このディレクティブの適切なサイズです。

client_max_body_size：クライアント要求に許可される最大サイズ。最大サイズを超えると、Nginxは413エラーまたは Request Entity TooLargeを吐き出します。

large_client_header_buffers：大きなクライアントヘッダーのバッファーの最大数とサイズ。

client_body_buffer_size 10K;
client_header_buffer_size 1k;
client_max_body_size 8m;
large_client_header_buffers 2 1k;

タイムアウト

タイムアウトは、パフォーマンスを大幅に向上させることもできます。

client_body_timeoutおよびclient_header_timeoutディレクティブは、サーバーが要求後にクライアント本体またはクライアントヘッダーが送信されるのを待機する時間を担当します。本文もヘッダーも送信されない場合、サーバーは408エラーまたはリクエストタイムアウトを発行します。

keepalive_timeoutは、クライアントとのキープアライブ接続のタイムアウトを割り当てます。簡単に言えば、Nginxはこの期間の後にクライアントとの接続を閉じます。

最後に、send_timeoutは、回答の転送全体ではなく、2つの読み取り操作の間でのみ確立されます。この時間の後にクライアントが何も取らない場合、Nginxは接続をシャットダウンしています。

client_body_timeout 12;
client_header_timeout 12;
keepalive_timeout 15;
send_timeout 10;

Gzip圧縮

Gzipは、Nginxが処理するネットワーク転送の量を減らすのに役立ちます。ただし、サーバーがCPUサイクルを浪費し始めるため、gzip_comp_levelを高くしすぎることに注意してください。

gzip             on;
gzip_comp_level  2;
gzip_min_length  1000;
gzip_proxied     expired no-cache no-store private auth;
gzip_types       text/plain application/x-javascript text/xml text/css application/xml;

静的ファイルキャッシング

変更されず、定期的に提供されるファイルに有効期限ヘッダーを設定することができます。このディレクティブは、実際のNginxサーバーブロックに追加できます。

location ~* .(jpg|jpeg|png|gif|ico|css|js)$ {
expires 365d;
}

Nginxサーバーのファイルの種類と一致するように、上記の配列のファイルの種類を追加および削除します。

ロギング

Nginxは、VPSにヒットするすべてのリクエストをログファイルに記録します。分析を使用してこれを監視する場合は、この機能をオフにすることをお勧めします。 access_logディレクティブを編集するだけです。

access_log off;

ファイルを保存して閉じてから、次のコマンドを実行します。

sudo service nginx restart

結論

結局のところ、適切に構成されたサーバーは、それに応じて監視および調整されるサーバーです。上記の変数はいずれも石に設定されておらず、それぞれの固有のケースに合わせて調整する必要があります。さらに先では、負荷分散と水平スケーリングの研究により、マシンのパフォーマンスをさらに向上させたいと考えているかもしれません。これらは、優れたシステム管理者がサーバーに対して行うことができる多くの拡張機能のほんの一部です。

投稿者： https ：//twitter.com/alexkavon

getdocs

13036