nginx が Apache より速い理由

nginx が Apache より速いのはなぜですか?

一般的ないくつかの概念について話しましょう:

1: nginx は同時実行性が高い場合は Apache より高速であり、同時実行性が低いことは明らかではありません

2: 速い理由は nginx の epoll モデルによるものです

apache はマルチスレッドまたはマルチプロセスです。動作しているとき、http 応答が来ると、 1 つのプロセスがそれを受信 (リッスン) -> 識別処理 -> リクエストを返す。このプロセス中、プロセスはすべてを処理します。apche はソケット I/O の読み取りまたは書き込みを行いますが、読み取りまたは書き込みはブロックされます。ブロックとは、プロセスが次のことを行う必要があることを意味します。サスペンドされてスリープ状態に入る 接続が多くなると必然的にApacheはリクエストに応答するプロセスを多く生成する プロセスが多くなるとCPUが頻繁にプロセスを切り替えてリソースと時間を消費するため、Apacheがダウンしてしまうはっきり言って、それほど多くのプロセスを処理できません。

Nginx は、非同期でノンブロッキングの epoll モデルを採用しています。 Nginx の場合、完全な接続要求処理は一度に 1 つのイベントに分割されます。たとえば、accept()、receive()、ディスク I/O、send() など、各部分には処理する対応するモジュールがあり、完全なリクエストは数百のモジュールによって処理される場合があります。本当のコアはイベント収集および配布モジュールであり、すべてのモジュールを管理する中核となります。

コア モジュールのスケジューリングのみが、対応するモジュールがリクエストを処理するために CPU リソースを占有することを許可できます。 HTTP リクエストを例に挙げると、まず、対象のリッスン イベントをイベント収集および配信モジュールに登録します。登録後は、ブロックせずに直接リターンします。その後は、特に心配する必要はありません。カーネルが通知するタイミングで通知されます。接続が来ます (epoll の番です)。クエリがプロセスに伝えます)、CPU は他のことを処理できます。

リクエストが来ると、リクエスト全体に対応するコンテキストが割り当てられます(実際には事前に割り当てられています)。このとき、新たに注目するイベント(read関数)が登録されます。クライアント データが来ると、カーネルはデータを読み取れることがプロセスに自動的に通知されます。データを読み取った後、解析されます。解析後、リソース (I/O) を見つけるためにディスクに移動します。I/O が完了すると、が完了すると、プロセスに通知が送られ、プロセスはクライアント send() へのデータの送信を開始します。現時点ではブロックされていません。呼び出し後は、カーネルが通知結果を送り返すのを待つだけです。

リクエスト全体は多くのステージに分割されており、各ステージは多くのモジュールに登録され、すべて非同期かつノンブロッキングで処理されます。ここでの非同期とは、結果が返されるのを待たずに何かを実行することを指し、完了すると自動的に通知されます。

インターネットで例を見つけました:

Apache のワークフローを説明するための簡単な例を挙げることができます。私たちは通常、レストランに食事に行きます。レストランの稼働モデルは、常に 1 人のウェイターが顧客にサービスを提供するというもので、ウェイターはドアのところで客を待ち（聞く）、客が到着したら、用意されたテーブルに挨拶する（受付）、顧客の注文を待ち (リクエスト uri)、キッチンに行きシェフを呼びます。料理の注文を出し (ディスク I/O)、キッチンの準備が整うのを待ち (読み取り)、料理を提供します。ゲスト (送信) ウェイター (プロセス) は多くの場所でブロックされています。

このように、ゲストが増えると (HTTP リクエストが増えると)、レストランはサービスを提供するためにより多くのウェイターを呼び出すことしかできません (フォーク プロセス)。ただし、レストランのリソースは限られているため (CPU)、ウェイターが多すぎると管理コストが発生し、非常に高い (CPU コンテキスト スイッチング) ため、ボトルネックになります。

Nginx がそれをどのように処理するかを見てみましょう?レストランのドアにドアベルを掛けます (epoll モデルのリッスンを登録します)。ゲスト (HTTP リクエスト) が到着すると、ウェイターがそれを受け取る (受け入れる) ために送信されます。その後、ウェイターは他の作業に移ります (ゲストが食事を注文したら、ウェイターに電話します (データは read() で到着します)。ウェイターが来て、メニューをキッチンに持って行きます (ディスク I/O)。ウェイターは他のことをしに行きます。キッチンの準備ができたら、ウェイターを呼び出します (ディスク I/O)。O 終了)、ウェイターはゲストに料理を提供します (send())、キッチンは 1 つの料理を提供します準備ができたらゲストに提供し、ウェイターはその間に他のことを行うことができます。

プロセス全体は多くのステージに分割されており、各ステージには対応するサービス モジュールがあります。ゲストが増えたら、レストランもより多くの人を収容できるように考えてみましょう。

Nginx の技術記事の詳細については、Nginx の使用方法チュートリアル 列をご覧ください。

以上がnginx が Apache より速い理由の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。