nginxを正しく構成するトピックは非常に大きく、私は恐れていますが、ハブに関する1つの記事のフレームワークには適合しません このテキストでは、構成の一般的な構造、より興味深い小さなこと、特におそらく、後で説明することについて話そうとしました。 :)
nginxを構成するための良い出発点は、配布キットに付属する構成ですが、このサーバーの非常に多くの機能は言及されていません。 より詳細な例は、Igor SysoevのWebサイト
sysoev.ru/nginx/docs/example.htmlにあります。 ただし、ブリッジと詩人を使用して、ゼロから構成を組み立てる方が良いでしょう。 :)
一般的な設定から始めましょう。 最初に、nginxが動作するユーザーに代わってユーザーを指定します（ルートからは動作が悪くなります。誰もが知っている:)）
user nobody;
ここで、nginxが生成する作業プロセスの数を考えてみましょう。 通常、適切な選択は、サーバーのプロセッサコアの数に等しいプロセスの数ですが、この設定で実験することは理にかなっています。 ハードディスクに高負荷が予想される場合、すべての作業はパフォーマンスによって制限されるため、物理ハードディスクごとにプロセスを実行できます。
worker_processes 2;
エラーログを書き込む場所を明確にします。 次に、個々の仮想サーバーについて、このパラメーターをオーバーライドして、たとえばサーバーの起動に関連する「グローバル」エラーのみがこのログに書き込まれるようにすることができます。
error_log /spool/logs/nginx/nginx.error_log notice; # "notice", ,
今、非常に興味深いセクション「イベント」があります。 その中で、1つのワーカープロセスが同時に処理する接続の最大数と、OSでイベントの非同期通知を受信するために使用されるメソッドを指定できます。 もちろん、OSで使用でき、コンパイル中に含まれていたメソッドのみを選択できます。
これらのオプションは、サーバーのパフォーマンスに大きな影響を与える可能性があります。 OSとアイロンに応じて、個別に選択する必要があります。 いくつかの一般的なルールしか説明できません。
イベントモジュール：
-通常、selectとpollは遅く、プロセッサの負荷が非常に高くなりますが、ほとんどすべての場所で利用可能であり、ほぼ常に動作します。
-kqueueとepollはより効率的ですが、それぞれFreeBSDとLinux 2.6でのみ利用可能です。
-rtsigはかなり効果的な方法であり、非常に古いLinuxでもサポートされていますが、多数の接続で問題を引き起こす可能性があります。
-/ dev / poll-私の知る限り、Solarisなどのよりエキゾチックなシステムで動作し、非常に効果的です。
Worker_connectionsパラメーター：
-提供されるクライアントの合計最大数は、worker_processes * worker_connectionsに等しくなります。
-場合によっては、128プロセス、プロセスごとの128接続、1プロセスなどの最も極端な値でも、パラメーターworker_connections = 16384を使用すると、正の方向で機能する場合があります。 ただし、後者の場合は、OSを調整する必要があります。
events {
worker_connections 2048;
use kqueue; # BSD :)
}
次のセクションは最大で、最も興味深いセクションが含まれています。 これは、仮想サーバーと、それらすべてに共通するいくつかのパラメーターの説明です。 ログへのパスなど、各構成にある標準設定は省略します。
http {
# %)
# ...
}
このセクションの中には、かなり興味深いパラメーターがあるかもしれません。
Linuxでは、sendfileシステムコールが比較的最近登場しました。 アプリケーションのアドレス空間にコピーする段階をバイパスして、ネットワークにデータを送信できます。 多くの場合、これによりサーバーのパフォーマンスが大幅に向上するため、sendfileパラメーターを常に含めることをお勧めします。
sendfile on;
keepalive_timeoutパラメーターは、ユーザーがキープアライブ接続から何も要求しない場合に、キープアライブ接続を維持するための最大時間を担当します。 リクエストがサイトに送信される方法を正確に検討し、この設定を修正します。 AJAXを積極的に使用するサイトの場合、接続をより長く維持することをお勧めします。ユーザーが長時間読む静的なページの場合、接続を早期に切断することをお勧めします。 非アクティブなキープアライブ接続を維持することにより、異なる方法で使用される可能性のある接続を占有していることに注意してください。 :)
keepalive_timeout 15;
それとは別に、nginxプロキシ設定を強調する価値があります。 ほとんどの場合、nginxはプロキシサーバーとしてそれぞれ正確に使用され、非常に重要です。 特に、プロキシされるリクエストのバッファサイズを、バックエンドサーバーからの応答の予想サイズ以上に設定することは理にかなっています。 遅い（または逆に非常に速い）バックエンドでは、バックエンドからの応答を待つためのタイムアウトを変更するのが理にかなっています。 これらのタイムアウトが長いほど、ユーザーがバックエンドブレーキを使用して回答を待つ時間が長くなることに注意してください。
proxy_buffers 8 64k;
proxy_intercept_errors on;
proxy_connect_timeout 1s;
proxy_read_timeout 3s;
proxy_send_timeout 3s;
ちょっとしたトリック。 nginxが複数の仮想ホストを提供する場合、サーバーがクライアントのリクエストのHostヘッダーで別の代替を見つけることができない場合にリクエストを処理する「デフォルトの仮想ホスト」を作成することは理にかなっています。
# default virtual host
server {
listen 80 default;
server_name localhost;
deny all;
}
次に、「サーバー」の1つ（または複数）のセクションが続きます。 それぞれが仮想ホスト（ほとんどの場合、名前ベース）を記述します。 1つのホスティング上の複数のサイトの所有者、またはホスティング業者の場合、ディレクティブのようなものがあるかもしれません
include /spool/users/nginx/*.conf;
残りは、ほとんどの場合、メイン構成で仮想ホストを直接記述します。
server {
listen 80;
# , server_name .
server_name myserver.ru myserver.com;
access_log /spool/logs/nginx/myserver.access_log timed;
error_log /spool/logs/nginx/myserver.error_log warn;
# ...
リコイルのデフォルトのエンコードを設定します。
charset utf-8;
そして、1メガバイトより長いクライアントからの要求を受け入れたくないとしましょう。
client_max_body_size 1m;
サーバーに対してSSIを有効にし、1キロバイト以下を予約するためにSSI変数を要求します。
ssi on;
ssi_value_length 1024;
最後に、ポート9999で実行されているApacheへのバックエンドにつながる2つの場所と、ローカルファイルシステムから静的な画像を提供する2つの場所について説明します。 2つの場所ではこれはほとんど意味がありませんが、より大きな数では、サーバーのルートディレクトリが格納される変数をすぐに決定し、場所の説明で使用することも意味があります。
set $www_root "/data/myserver/root";
location / {
proxy_pass 127.0.0.1:9999;
proxy_set_header X-Real-IP $remote_addr;
proxy_intercept_errors off;
proxy_read_timeout 5s; # , ,
proxy_send_timeout 3s;
# ...
ルートの別のブロックは、結果をgzipに圧縮するために専用です。 これにより、あなたとあなたのユーザーはトラフィックを節約できます。 Nginxは、圧縮するファイルの種類（または、この場合はバックエンドからの応答）、および圧縮を使用するために必要な最小ファイルサイズを指定できます。
# ...
gzip on;
gzip_min_length 1024;
gzip_proxied expired no-cache no-store private auth;
gzip_types text/plain application/xml;
}
location /i/ {
root $www_root/static/;
}
}
ご清聴ありがとうございました。 そして、申し訳ありませんが、投稿が非常に長いことが判明しました。