Nginx が Apache より優れている理由

Nginx は、わずか数年で Web サーバー市場の大部分を占めるようになりました。周知のとおり、Nginx は大量の同時静的リクエストの処理において Httpd よりもはるかに効率的であり、C10K 問題も簡単に解決できます。

同時接続数が多い場合、Nginx は Apache サーバーの優れた代替手段となります。 Nginx はレイヤー 7 負荷分散サーバーとしても使用できます。私のテスト結果によると、Nginx + PHP (FastCGI) は 30,000 以上の同時接続を処理でき、これは同じ環境下での Apache の 10 倍です。

一般的に、4GB のメモリ + Apache (プリフォーク モード) を搭載したサーバーでは、同時接続が 3,000 件しか処理できません。これは、同時接続によって 3GB を超えるメモリが占​​有され、1GB のメモリをシステム用に予約する必要があるためです。かつて 2 台の Apache サーバーがありました。設定ファイルの MaxClients 設定が 4000 だったため、同時 Apache 接続数が 3800 に達すると、サーバーのメモリとスワップ領域がいっぱいになり、クラッシュしました。

30,000 の同時接続がある場合、この Nginx + PHP (FastCGI) サーバーは、開いている 10 個の Nginx プロセスに 150M のメモリ ( 15M*10=150M ) を消費し、開いている 64 個の php-cgi プロセスに 1280M のメモリ ( 20M*64=1280M ) を消費します。システム自体が消費するメモリと合わせると、消費されるメモリの合計は 2GB 未満です。サーバーのメモリが小さい場合は、php-cgi プロセスを 25 個起動するだけで、php-cgi によって消費されるメモリの合計は 500 MB のみになります。

同時接続数が 30,000 の場合、Nginx+ PHP (FastCGI) サーバーにアクセスする PHP プログラムは依然として非常に高速です。

高い同時実行性の処理において、Nginx が httpd よりも優れているのはなぜでしょうか? まず、2 つの Web サーバーの動作原理と動作モードから始めましょう。

1. Apacheの3つの動作モード

Apache には prefork、worker、event という 3 つの作業モジュールがあることは誰もが知っています。

• prefork: 複数のプロセスがあり、各要求はプロセスによって応答され、このプロセスは選択メカニズムを使用して通知します。
• ワーカー: マルチスレッド、プロセスは複数のスレッドを生成でき、各スレッドは 1 つの要求に応答しますが、通知メカニズムは引き続き選択され、より多くの要求を受け入れることができます。イベント: 非同期 I/O モデルに基づき、1 つのプロセスまたはスレッドで、各プロセスまたはスレッドが複数のユーザー要求に応答し、イベント駆動型 (つまり、epoll メカニズム) に基づいて実装されます。

1. プリフォークの動作原理

「--with-mpm」で MPM を明示的に指定しない場合、Unix プラットフォームでは prefork がデフォルトの MPM になります。使用される事前フォークされた子プロセス方式は、Apache1.3 でも使用されるモデルです。

Prefork 自体はスレッドを使用しません。バージョン 2.0 では、バージョン 1.3 との互換性を維持するためにスレッドを使用しています。一方、prefork は、異なるリクエストを処理するために個別の子プロセスを使用し、プロセスは互いに独立しているため、最も安定した MPM の 1 つとなっています。

2. 労働者の労働原理

prefork と比較すると、worker はバージョン 2.0 のまったく新しい MPM であり、マルチスレッドとマルチプロセスのハイブリッド モデルをサポートします。処理にはスレッドが使用されるため、比較的多くのリクエストを処理でき、システム リソースのオーバーヘッドはプロセス ベースのサーバーよりも少なくなります。

ただし、ワーカーも複数のプロセスを使用し、各プロセスは複数のスレッドを生成することで、プロセスベースのサーバーの安定性を確保します。この MPM 動作モードは、Apache2.0 の開発トレンドになります。

3. イベントベースの機能

プロセスは複数のユーザー要求に応答し、コールバック機構を使用してソケットを再利用します。要求が到着した後、プロセスは要求を処理せず、他の機構に直接引き渡して処理し、epoll 機構を使用して要求が完了したかどうかを通知します。このプロセスでは、プロセス自体は常にアイドル状態にあり、ユーザー要求を引き続き受信できます。プロセスは複数のユーザー要求に応答できます。大量の同時接続をサポートし、消費するリソースが少なくなります。

2. Webサーバーの同時接続処理能力を向上させる方法

基本的な条件はいくつかあります。

1. スレッドベース。つまり、1 つのプロセスが複数のスレッドを生成し、各スレッドがユーザーからの各要求に応答します。

2. イベントベース モデルでは、プロセスが複数の要求を処理し、epoll メカニズムを通じてユーザーに要求の完了を通知します。

3. ディスクベースのAIO（非同期I/O）

4. mmap メモリ マッピングをサポートします。従来の Web サーバーは、ページを入力するときに、まずディスク ページをカーネル キャッシュに入力し、次にカーネル キャッシュから Web サーバーにコピーします。mmap メカニズムは、カーネル キャッシュをディスクにマッピングし、Web サーバーがページの内容を直接コピーできるようにすることです。最初にディスク上のページをカーネル キャッシュにインポートする必要はありません。

実は、Nginx は上記の機能をすべてサポートしています。したがって、Nginx は 50,000 の同時接続をサポートするという Nginx 公式 Web サイトの記述は根拠が十分あります。

3. Nginxの優秀さ

従来、プロセスまたはスレッド モデル アーキテクチャに基づく Web サービスは、各プロセスまたは各スレッドを通じて同時接続要求を処理するため、ネットワークおよび I/O 操作中にブロックが発生します。また、メモリまたは CPU の使用率が低下することも避けられません。

新しいプロセス/スレッドを生成するには、ヒープ メモリとスタック メモリの割り当て、新しい実行コンテキストの作成など、ランタイム環境を事前に準備する必要があります。これらの操作には CPU の使用が必要であり、プロセス/スレッドが多すぎるとスレッドのジッターや頻繁なコンテキスト切り替えが発生し、システム パフォーマンスがさらに低下します。

もう 1 つの高性能 Web サーバー / Web サーバー リバース プロキシは Nginx です。Nginx の主な焦点は、物理コンピューティング リソースの高性能と高密度利用であるため、異なるアーキテクチャ モデルを採用しています。さまざまなオペレーティング システムの設計における高度な「イベント」ベースの処理メカニズムにヒントを得て、Nginx はモジュール式、イベント駆動型、非同期、シングル スレッド、非ブロッキングのアーキテクチャを採用し、多重化およびイベント通知メカニズムを広範に活用しています。

Nginx では、接続要求は、効率的な実行ループ メカニズムを使用して 1 つのスレッドのみを含む少数のワーカー プロセスによって処理され、各ワーカーは数千の同時接続と要求を並行して処理できます。

4. Nginxの仕組み

Nginx は、必要に応じて、マスター プロセスと複数のワーカー プロセスという複数のプロセスを同時に実行します。キャッシュが構成されている場合は、キャッシュ ローダー プロセスとキャッシュ マネージャー プロセスも実行されます。すべてのプロセスには 1 つのスレッドのみが含まれ、プロセス間通信は主に「共有メモリ」メカニズムを通じて実現されます。メイン プロセスは root として実行されますが、ワーカー、キャッシュ ローダー、キャッシュ マネージャーはすべて権限のないユーザーとして実行する必要があります。

同時接続数が多い場合、Nginx は Apache サーバーの優れた代替手段となります。

Nginx はインストールが非常に簡単で、設定ファイルも非常に簡潔 (perl 構文もサポート) であり、サーバーにバグはほとんどありません。Nginx は起動が非常に簡単で、ほぼ 7*24 ノンストップで実行でき、数か月間実行しても再起動する必要はありません。また、サービスを中断することなくソフトウェア バージョンをアップグレードすることもできます。

5. Nginxの誕生は主にC10K問題を解決する

最後に、それぞれで使用される多重化 IO モデルの観点から分析します。

1. モデルを選択します: (Apache で使用されますが、モジュールなどの制限によりあまり使用されません)。

1 つのプロセスが監視できるファイル記述子の数には上限があります。

select() によって管理されるデータ構造には、多数のファイル記述子が格納されます。ファイル記述子の数が増えると、ユーザー モードとカーネル間でアドレス空間をコピーすることによって発生するオーバーヘッドも直線的に増加します。

ネットワーク応答時間の遅延により、多数の TCP 接続が非アクティブになりますが、select() を呼び出すとすべてのソケットに対して線形スキャンが実行され、一定のオーバーヘッドが発生します。

2. poll: poll は Unix による select の再実装です。poll が解決する唯一の問題は、poll にはファイル記述子の最大数に制限がないことです。

3. epoll モデル: (Nginx で使用)

Epoll には 2 つの利点があり、パフォーマンスが大幅に向上します。

1) イベントベースの準備完了通知方法である選択/ポーリング方式に基づいて、カーネルはプロセスが特定のメソッドを呼び出した後にのみ監視対象のすべてのファイル記述子をスキャンし、epollイベントはepoll_ctl()を介してファイル記述子を登録します。ファイル記述子の準備が完了すると、カーネルはコールバックに似たコールバックメカニズムを使用してファイル記述子を迅速にアクティブ化し、epoll_wait()に通知されます。

2) 準備完了のファイル記述子を取得するために epoll_wait() を 1 回呼び出すと、返されるのは実際の記述子ではなく、準備完了の記述子の数を表す値です。これらの値は、epoll で指定された配列に取り込まれ、対応する数のファイル記述子が順番に取得されます。ここでは、大量のファイル記述子をコピーするオーバーヘッドを回避するために、メモリ マッピング (mmap) テクノロジが使用されています。

3) もちろん、epoll にも一定の制限があります。epoll は Linux 2.6 にのみ実装されており、他のプラットフォームには実装されていません。これは明らかに、Apache などの優れたクロスプラットフォーム サーバーとは相反するものです。

4) 簡単に言えば、epoll は select のアップグレード版であり、単一のプロセスによって管理されるファイル記述子に最大制限はありません。ただし、epoll は Linux プラットフォームでのみ利用可能です。クロスプラットフォームのApacheは使用されていない

出典: http://codebay.cn/post/8557.html

これで、Nginx が Apache より優れている理由に関するこの記事は終了です。Nginx と Apache の詳細については、123WORDPRESS.COM の以前の記事を検索するか、次の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。