Nginx2: 動作メカニズム

プロセスとスレッドはメモリやその他のシステムリソースを消費し、コンテキストスイッチが必要であることはわかっています。最新のサーバーのほとんどは、数百のプロセスまたはスレッドを同時に処理できますが、メモリが使い果たされるとパフォーマンスが低下し、IO 負荷が高いときにコンテキストの切り替えが頻繁に発生します。
ネットワークに対処する従来の方法は、接続ごとにプロセスまたはスレッドを作成することでした。この方法は実装は簡単ですが、拡張するのは困難です。

それでは、Nginxはどうやってやるのでしょうか？ How Does NGINX Work?

nginxが起動すると、マスタープロセスと複数のワーカープロセスが存在します。マスター プロセスは主にワーカー プロセスの管理に使用されます。これには、外部からのシグナルの受信、各ワーカー プロセスへのシグナルの送信、ワーカー プロセスの実行ステータスの監視、ワーカー プロセスの終了時に新しいワーカー プロセスを自動的に再起動するなどが含まれます。異常事態）。基本的なネットワーク イベントはワーカー プロセスで処理されます。複数のワーカー プロセスはピアツーピアであり、クライアントからのリクエストを平等に競合し、各プロセスは互いに独立しています。リクエストは 1 つのワーカー プロセスでのみ処理でき、ワーカー プロセスは他のプロセスからのリクエストを処理できません。ワーカー プロセスの数は、通常、マシンの CPU コアの数に合わせて設定できます。これは、nginx のプロセス モデルとイベント処理モデルと切り離すことができません。 nginx のプロセス モデルは次の図で表すことができます:

ご覧のとおり、ワーカー プロセスはマスターによって管理されます。マスター プロセスは外部から信号を受信し、その信号に基づいてさまざまな処理を実行します。したがって、nginx を制御したい場合は、マスタープロセスにシグナルを送信するだけで済みます。たとえば、./nginx -s reload は nginx を再起動します。このコマンドは、まずマスター プロセスにシグナルを送信し、シグナルを受信した後、新しいプロセスを開始し、プロセスはすべての古いプロセスに正常にリタイアできるというシグナルを送信します。新しいプロセスが開始されると、新しいリクエストの受信を開始しますが、古いプロセスはマスターからシグナルを受信した後、現在のプロセス内の未処理のリクエストがすべて処理された後、新しいリクエストを受信しなくなり、終了します。
では、ワーカー プロセスはリクエストをどのように処理するのでしょうか?
前述したように、ワーカー プロセスは平等であり、各プロセスにはリクエストを処理する同じ機会があります。ポート 80 で http サービスを提供すると、接続要求が来て、各プロセスがこの接続を処理することができます。まず、各ワーカープロセスがマスタープロセスからフォークします。マスタープロセスでは、まずリッスンする必要のあるソケットが確立され、次に複数のワーカープロセスがフォークされ、各ワーカープロセスがソケットを受け入れることができます（もちろんそうではありません）。同じソケットですが、各プロセスのソケットは同じ IP アドレスとポートを監視します。これはネットワーク プロトコルで許可されています。 nginx は accept_mutex というものを提供します。名前から、これが受け入れるために追加された共有ロックであることがわかります。このロックを使用すると、同時に accpet に接続するプロセスは 1 つだけになります。 accept_mutex は、明示的にオフにできる制御可能なオプションです。デフォルトではオンになっています。ワーカー プロセスは接続を受け入れると、リクエストの読み取り、解析、リクエストの処理、データの生成を開始し、それをクライアントに返し、最後に接続を切断します。これが完全なリクエストです。リクエストはワーカー プロセスによって完全に処理され、1 つのワーカー プロセスでのみ処理されることがわかります。
では、nginx がこのプロセス モデルを採用するメリットは何でしょうか?
1) 各ワーカー プロセスは独立しており、ロックを必要としないため、ロックのオーバーヘッドが排除され、プログラミングが簡単になります。
2) プロセスは互いに独立しており、1 つのプロセスが終了した後 (たとえば、例外が発生した場合)、他のプロセスは通常どおり動作し、サービスは中断されません。
３）コンテキストスイッチングがないため、不要なシステムオーバーヘッドが削減されます

Nginxは、Linuxのepollのようなシステムコールであるイベント駆動型の処理機構を採用しています。複数のイベントを同時に監視でき、タイムアウトを設定できます。タイムアウト内でイベントの準備が完了すると、準備されたイベントが返されます。このようにして、イベントの準備ができている限りそれを処理し、すべてのイベントの準備ができていない場合にのみ、epoll でブロックして待機します。このようにして、リクエスト間で継続的に切り替えを行うことができ、イベントの準備ができていないため、積極的に中止されます。ここでの切り替えにはコストはかかりません。これは、準備された複数のイベントをループで処理するものとして単純に理解できます。
マルチスレッドと比較すると、このイベント処理方法には、スレッドを作成する必要がなく、各リクエストが占有するメモリが非常に少なく、コンテキストの切り替えがなく、イベント処理が非常に軽量であるという大きな利点があります。同時実行がどれほど多くても、不必要なリソースの浪費 (コンテキストの切り替え) が発生することはありません。同時実行性が高くなると、より多くのメモリを占有するだけになります。これが、nginx のパフォーマンスが効率的になる主な理由でもあります。

以下はNginx公式サイトより抜粋です
NGINX サーバーがアクティブな場合、ワーカー プロセスのみがビジー状態になり、各ワーカー プロセスは非ブロッキング方式で複数の接続を処理し、コンテキスト スイッチの数を減らします。 各ワーカー プロセスはシングルスレッドで独立して実行され、新しい接続を取得して処理します。プロセスは、共有キャッシュ データ、セッション永続データ、その他の共有リソースの共有メモリを使用して通信できます。各 NGINX ワーカー プロセスは NGINX で初期化されます。構成に含まれており、マスター プロセスによってリッスン ソケットのセットが提供されます。 NGINX ワーカー プロセスは、リッスン ソケット (accept_mutex およびカーネル ソケット シャーディング) でイベントを待機することから始まり、新しい受信接続によってイベントが開始されます。これらの接続はステート マシンに割り当てられます。最も一般的に使用されるのは HTTP ステート マシンです。ストリーム (生の TCP) トラフィックおよび多数のメール プロトコル (SMTP、IMAP、POP3) のステート マシンも実装します。

著作権に関する声明: この記事はブロガーによるオリジナルの記事であり、ブロガーの許可。

以上、Nginx2 の動作メカニズムをさまざまな側面を含めて紹介しましたが、PHP チュートリアルに興味のある友人に役立つことを願っています。