Nginx はパフォーマンスとスケールを考慮してどのように設計されていますか?

ネットワーク アプリケーションにおける NGINX の卓越したパフォーマンスは、そのユニークな設計にあります。多くのネットワーク サーバーやアプリケーション サーバーは、ほとんどがスレッドまたはプロセスに基づく単純なフレームワークです。NGINX で際立っているのは、最新のハードウェア上で数千の同時接続を処理できる、成熟したイベント駆動型フレームワークです。
NGINX 内部インフォグラフィックは、プロセス フレームワークの最上位レベルから始まり、NGINX が 1 つのプロセスで複数の接続をどのように処理するかを明らかにし、その仕組みをさらに調査するために下位レベルに進みます。
シナリオ設定 - NGINX プロセス モデル

この設計パターンをより深く理解するには、NGINX がどのように動作するかを理解する必要があります。 NGINX には、設定ファイルの読み取りやポートのバインドなどの特権操作を処理するメイン スレッドと、一連のワーカー プロセスおよび補助プロセスがあります。

# service nginx restart

* nginx を再起動します

# ps -ef --forest grep nginx

root 32475 1 0 13:36 ? 00:00:00 nginx: マスター プロセス /usr/sbin /nginx

-c /etc/nginx/nginx.conf

nginx 32476 32475 0 13:36 ? 00:00:00 _ nginx: ワーカープロセス

nginx 32477 32475 0 13:00:00 _ nginx: ワーカープロセス

nginx 32479 32475 0 13:36 _ nginx: ワーカープロセス

nginx 32480 32475 0 13:36 ? 00:00:00 _ nginx: ワーカープロセス

nginx 32481 32475 0 13:36 ? 00: 00:00 _ nginx: キャッシュ マネージャー プロセス

nginx 32482 32475 0 13:36 ? 00:00:00 _ nginx: キャッシュ ローダー プロセス

このクアッドコア サーバーでは、メイン スレッドは 4 つのワーカーを作成しますプロセスと、ハードディスク キャッシュを管理する一連のキャッシュ ヘルパー プロセス。
フレームワークはなぜそれほど重要なのでしょうか?
Unix アプリケーションの基礎はスレッドまたはプロセスです。Linux オペレーティング システムの場合、スレッドとプロセスはほぼ同じであり、最大の違いはメモリがスレッド間で共有されることです。スレッドまたはプロセスは、オペレーティング システムが単一の CPU コアで実行するようにスケジュールする自己完結型の命令セットです。多くの複雑なアプリケーションは、次の 2 つの理由により、複数のスレッドまたはプロセスで並行して実行されます。

アプリはコンピューターの複数のCPUコアを同時に使用できます

複数の接続を同時に処理するなど、スレッドとプロセスは簡単に並列操作できます

プロセススレッドは、メモリや他のオペレーティング システム リソースの占有、コアの切り替え (コアのオンとオフの切り替え) などのリソースを消費します (この操作はコンテキスト スイッチと呼ばれます)。今日のサーバーは、数千の小さなアクティブなスレッドまたはプロセスを同時に処理する必要があり、メモリが使い果たされたり、読み取りおよび書き込みの負荷が高すぎると、大規模なコンテキストの切り替えが発生し、パフォーマンスが大幅に低下します。
通常の設計上の考え方は、ネットワーク アプリケーションが接続ごとにスレッドまたはプロセスを割り当てるというものです。このタイプのフレームワークはシンプルで実装が簡単ですが、数千の接続を同時に処理する場合は拡張が困難です。
NGINX はどのように機能しますか?
NGINX は、予測プロセス モデルを利用して、利用可能なハードウェア リソースをスケジュールします。

メイン プロセスは、構成ファイルの読み取り、ポート バインドなどの特権操作を処理するだけでなく、小規模な子プロセスのセット (次の 3 種類のプロセス)

キャッシュ ローダー プロセスは、起動時にハードディスクからメモリにキャッシュをロードして終了します。スケジューリングは保守的であるため、リソースのオーバーヘッドは低くなります

キャッシュ管理プロセスは定期的に実行され、ハードディスク キャッシュからエンティティを指定されたサイズまで消去します

ワーカー プロセスは、ネットワーク接続の処理、ハードウェアの処理など、すべての作業を担当します。ディスクの読み取り、書き込み操作、およびアップストリームのサーバー通信

NGINX の推奨構成は、ハードウェア リソースを効果的に使用するために、1 つのワーカー プロセスが 1 つの CPU コアに対応することです:

worker_processes auto;

NGINX が提供されると、ワーカー プロセスのみがビジーになり、各ワーカー プロセスは複数の接続をノンブロッキングで処理するため、コンテキスト スイッチの数が減ります。
各ワーカー プロセスはシングルスレッドで独立して実行され、新しい接続の取得と処理を担当します。プロセスは、キャッシュ データ、セッション永続データ、その他の共有リソースなどの共有メモリを介して通信します。 NGINX 1.7.11 以降のバージョンには、ワーカー プロセスがブロック操作をスローするオプションのスレッド プールがあります。詳細については、「Nginx がスレッド プールを導入してパフォーマンスを 9 倍向上」を参照してください。 NGINX Plus ユーザーの場合、これらの新機能は今年のリリース 7 で登場する予定です。
NGINX 内部作業プロセス

各 NGINX 作業プロセスは構成ファイルによって初期化され、メイン プロセスはそれにリスニング ソケットのセットを提供します。
ワーカー プロセスは、ソケット リスニング イベント (accept_mutex およびカーネル ソケット シャーディング) で開始され、イベントは新しい接続によって初期化され、その後、これらの接続がステート マシンにディスパッチされます。HTTP ステート マシンが最も一般的に使用されます。 . ですが、NGINX はストリームベースのステート マシンと通信プロトコル ベースのステート マシン (SMTP、IMAP、POP3) も実装しています。

ステート マシンは、NGINX に各リクエストの処理方法を指示する重要な命令セットです。多くの Web サーバーは NGINX のステート マシンと同じ機能を備えていますが、違いは実装にあります。
ステート マシンのスケジュール
ステート マシンはチェスのようなもので、単一の HTTP トランザクションはチェスのゲームのようなものです。チェス盤の一方の端には、非常に迅速に意思決定を行うグランドマスターのような Web サーバーがあり、もう一方の端には、比較的遅いネットワークを介してサイトまたはアプリケーションにアクセスする Web ブラウザであるリモート クライアントがあります。
ただし、ゲーム ルールは非常に複雑な場合があります。たとえば、ネットワーク サービスは、ゲーム ルールを拡張するために、サードパーティ、認証サーバー、またはサーバー内のサードパーティ モジュールと通信する必要がある場合があります。 。
ブロッキング ステート マシン
前の説明に戻ると、プロセスまたはスレッドは一連の命令であり、オペレーティング システムはそれを特定の CPU コアで実行するようにスケジュールします。ほとんどの Web サーバーと Web アプリケーションは、1 つの接続を処理する 1 つのプロセス、または 1 つの接続を処理する 1 つのスレッドのモデルに従ってチェスのゲームをプレイします。各プロセスまたは命令を含むスレッドはゲーム全体に参加します。この期間中、サーバー上で実行されているプロセスはほとんどの時間ブロックされ、クライアントが次の動作を完了するのを待っています。

ネットワークサーバープロセスは、ソケット上の新しい接続をリッスンします。この新しいゲーム接続はクライアントによって開始されます。

新しいゲームを取得してゲームセッションに入ると、移動するたびにクライアントの応答を待つ必要があり、プロセスはブロックされます。

ゲームが終了すると、ネットワーク サーバー プロセスは、クライアントが別のゲームをプレイしたいかどうかを確認します (接続が残っていることに対応します)。接続が閉じられると (クライアントが離れるかタイムアウトすると)、ネットワーク サーバー プロセスは新しいゲームの待機に戻ります。

アクティブな HTTP 接続、つまり各チェスのゲームには、チェス マスターなどの特定のプロセスまたはスレッドが参加する必要があることに注意してください。このアーキテクチャはシンプルで、サードパーティ モデルや新しいルールを拡張するのが簡単です。ただし、ここには非常に不均衡なロジックがあり、単一のファイル記述子と少量のメモリで表される軽量 HTTP 接続の場合、この接続はスレッドまたはプロセスにマップされ、スレッドまたはプロセスは重みレベルになります。オペレーティング システム オブジェクト。プログラミングする際には便利ですが、無駄が大きいです。
NGINX は本物のマスターです
おそらく、チェスのマスターが同時に 12 人のプレイヤーと対戦する同時ディスプレイ ゲームについて聞いたことがあるでしょう。

NGINX ワーカー プロセスも、この方法で「チェス」をプレイします。CPU コア上のワーカーは、同時に何千ものゲームを処理できるマスターです。

ワーカー プロセスは、接続されているソケットからイベントを取得し、リッスンを開始します

ソケットがイベントを受信すると、ワーカー プロセスはすぐにイベントを処理します。

ソケットでのリスニング イベントは、クライアントが新しいチェス ゲームを開始し、ワーカー プロセスが新しいソケット接続を作成することを意味します。

• ソケット接続上のイベントは、クライアントが移動し、ワーカー スレッドが適切に応答することです。

ワーカー プロセスは、相手 (クライアント) の応答を待っているネットワーク トランスポートをブロックすることはありません。各手ごとに、ワーカー プロセスは待機中の他のチェス ゲームを迅速に処理するか、新しいプレイヤーを歓迎します。

ブロッキングマルチプロセスフレームワークよりも速いのはなぜですか? NGINX は、数千の接続を処理する 1 つのワーカー スレッドをサポートしているため、優れたスケーラビリティを備えています。新しい接続ごとにファイル記述子が作成され、ワー​​カー プロセスの追加メモリのごく一部しか消費されず、追加のオーバーヘッドは非常にわずかです。プロセスは常に CPU に固定できるため、コンテキストの切り替えは比較的まれで、作業がない場合にのみ発生します。
翻訳者注: CPU バインディングとは、1 つまたは複数のプロセスを 1 つまたは複数のプロセッサにバインドすることを指します。ブロッキング方式を使用します。つまり、1 つの接続が 1 つのプロセスに対応し、各接続には多くの追加リソースとオーバーヘッドが必要です。 、コンテキストの切り替えが非常に頻繁に行われます。
(詳細については、NGINX アーキテクチャに関する Andrew Alexeev の記事を参照してください。著者は NGINX の共同創設者兼企業開発担当副社長です。)
システムが適切に調整されている限り、NGINX は機能しますこのプロセスは、何万もの同時 HTTP 接続を処理でき、問題なくネットワークのピークを処理できます。つまり、より多くのチェス ゲームを同時にプレイできます。
NGINX をアップグレードするには構成ファイルを更新します
プロセス フレームワークには少数のワーカー プロセスがあり、構成ファイルやバイナリ ファイルの更新が容易になります。

NGINX 構成の更新は、シンプルで軽量かつ信頼性の高い操作です。つまり、nginx -s reload コマンドを実行している限り、ディスク上の構成ファイルがチェックされ、SIGHUB シグナルがメイン プロセスに送信されます。
メインプロセスは SIGHUB を受信すると、次の 2 つのことを実行します:

設定ファイルをリロードし、新しく作成されたワーカープロセスのセットを直ちに作成し、接続を受け入れてネットワークを処理します。通信（新しい構成環境を使用）。

古いワーカー プロセスに通知して正常にロールアウトし、それらのワーカー プロセスが新しい接続の受け入れを停止しました。現在処理中の HTTP リクエストが終了すると、ワーカー プロセスは接続を閉じます。すべての接続が閉じられると、ワーカー プロセスは終了します。

プロセスを再ロードすると、CPU とメモリの使用量がわずかに増加しますが、アクティブな接続からリソースをロードする場合と比較してオーバーヘッドは最小限です。構成ファイルは 1 秒間に複数回リロードできます。クローズ待ちの接続を多数生成する NGINX ワーカー プロセスでは、通常、問題が発生することはほとんどありませんが、問題が発生した場合でも、すぐに解決できます。
NGINX バイナリ ファイルのアップグレードは、優れた高可用性を実現します。接続、サービス、またはサービスのダウンタイムや中断が失われることなく、オンラインでファイルをアップグレードできます。 翻訳者注: オンザフライでは、プログラムの実行中に作業を完了できます。

バイナリ ファイルのアップグレード プロセスは、エレガントな構成ファイルのリロードに似ています。新しい NGINX メイン プロセスは、元のメイン プロセスと並行して実行され、リスニング ソケットを共有します。両方のプロセスがアクティブで、それぞれのネットワーク通信を処理します。元のメインプロセスとそのワーカープロセスに正常に終了するように通知できます。
プロセスの詳細な説明については、NGINX Controlを参照してください
最終結論
NGINXの内部インフォグラフィックは、簡単な説明の背後にあるNGINXの高標準機能の全景を示しています。は 10 年以上の経験があり、継続的な革新と最適化のおかげで、NGINX はさまざまなハードウェア プラットフォームで広く使用され、最高のパフォーマンスを実現しています。現代でも、ネットワーク アプリケーションはセキュリティと信頼性を維持する必要があり、NGINX は非常に優れたパフォーマンスを発揮します。
NGINX の最適化について詳しく知りたい場合は、次の有益な情報を参照してください:

NGINX のインストール、パフォーマンス チューニング

NGINX のパフォーマンス チューニング

"Nginx では、スレッド プールが導入されていますパフォーマンスを9倍向上

NGINX - オープンソースアプリケーションフレームワーク

NGINXソケット分割(Socket Sharding)リリースバージョン1.9.1

転載元: Python開発者

上記では、Nginx がパフォーマンスとスケールを考慮してどのように設計されているかを紹介しました。 、関連コンテンツも含めて、PHP チュートリアルに興味のある友人に役立つことを願っています。