nginx は Apache よりも高速であるのに、なぜ nginx が Apache を置き換えないのでしょうか?

多くのクラウド ホスト統合環境やさまざまなパブリック クラウドでは、デフォルトで lighttpd または nginx サーバーが提供されています。なぜこれらの高性能サーバー ソフトウェアが Apache に置き換わらないのですか?

返信内容:

多くのクラウド ホスト統合環境やさまざまなパブリック クラウドでは、デフォルトで lighttpd または nginx サーバーが提供されています。なぜこれらの高性能サーバー ソフトウェアが Apache に置き換わらないのですか?

Nginx は Apache よりも明らかに軽くて効率的で、どちらも非常に安定しています。

Netcraft の統計によると、2016 年 2 月の最もビジーなサイト 100 万のうち、Apache は約 46%、Nginx は約 25%、IIS は 12% 未満でした。注目に値するのは、最もビジーなサイト 100 万の中で Nginx のシェアが占めていることです。は約25％と増加傾向を維持している一方、ApacheとIISはともに減少傾向を示している。つまり、同時実行性の高いWebサイトは、例えば国内のAlibabaが利用するTengineに移行する傾向にある。 Nginx の二次開発に基づいています。

ほとんどの仮想ホスト ユーザーにとって、帯域幅がボトルネックであるため、高い同時実行性は問題外であり、2M の帯域幅では同時実行性について話す必要はありません。さらに、Apache は設定を再ロードせずに .htaccess 設定をサポートしています。構成は Nginx よりも優れています。つまり、同時実行シナリオを追求していないのであれば、アーキテクチャを変更する必要はありません。そして使いやすいです。

Nginx は、Nginx の問題ではなく、バックエンドの問題が原因で 502 Bad Gateway エラーを返します
たとえば、リクエストの処理中にバックエンドの PHP-FPM プロセスがクラッシュすると、Nginx は 502 エラーを返します
もちろん、fastcgi_next_upstream を使用することもできます。処理のためにリクエストを別のアップストリームに転送するように Nginx を構成します。
fastcgi_next_upstream error timeout invalid_header http_500 http_502 http_504;
Nginx+PHP-FPM は、動的および静的な分離、負荷分散、フェイルオーバーを実現し、実際に同時実行性の高いシナリオでは Apache よりも優れた利点があります。 PHP モジュールは PHP を処理するときに静的リソースを処理できませんが、PHP の処理は動的リソースと静的リソースの分離である PHP-FPM の問題であるため、Nginx はこの問題を心配する必要はありません。 Apacheの場合もそうですが、ロードバランシングを実現するためのPHP-FPMクラスターの上流構成は苦手です
。

PHP-FPM を Nginx と組み合わせることで、I/O 集中型の操作を分離し、PHP アプリケーション全体に対するブロックの影響を軽減することもできます。

時間のかかる操作が主に発生するため、ユーザーのダウンロードと Curl リクエストは一般的な I/O 集中型の操作です。ネットワーク I/O とディスク I/O 上で動作します。
PHP 認証を必要とするダウンロード操作は、Nginx の AIO スレッド プールに委任できます。

header("X-Accel-Redirect: $filepath");curl 操作については、たとえば、io という名前の PHP-FPM プロセス プールを作成できます。ポート 9001 (プール) をリッスンします。
ポート 9000 でリッスンする www プロセス プールでカール操作がブロックされないように、カール操作 (Nginx 経由で分散) を処理することに特に責任があります。
現時点では、次のことは問題ではありません。 io プロセス プールでさらにプロセスを開きます:
リーリー

I/O 集中型プロセス プール [io] は、動的なプリフォーク プロセスを使用します。たとえば、ビジー状態では 8 個、アイドル状態では 4 個です。

PHP-FPM によって提供されるプールの分離を使用して、コンピューティング集中型操作と I/O 集中型操作を分離できます。 PHP アプリケーション全体に対するブロックの影響を軽減します。

断食に相当するのは安定性です。

同時実行性など、それほど高いパフォーマンス要件を必要としない一部の Web サイトでは、Apache の使用が適切な選択です。

この 2 つは焦点が異なるため、Apache 自体には多くの組み込み機能があり、他のものの助けを借りずにほぼすべての Web タイプのアプリケーションをサポートできます。 Nginx は、静的ファイル処理と高い同時実行性に利点があります。

Apache は完全性と安定性に重点を置き、Nginx は軽量性と高効率に重点を置いています。多くの場合、Apache と Nginx は Apache の前に構成され、静的ファイルのリクエスト (リソースのリクエスト) をブロックするために使用されます。部分的に）、Nginx が処理できないコンテンツは処理のために Apache に転送されます。

nginx は確かに優れていますが、すべての Web サイトが究極を追求するものを使用する必要があるわけではありません。結局のところ、人々は怠け者で新しいことを受け入れたがらず、リスクや責任を恐れているのです。

LAMP のポットは、一度インストールするとすぐに使用できるようになり、多くの人は問題に遭遇したとき、使い方を知っているものに適応するために 10 倍の作業時間を費やすことを学ぶ必要があると教えられました。この大きな穴を埋めるために100倍の時間を費やしたくないのです。新しいことを学ぶのに1日も費やしたくないのです。

すべてにメリットとデメリットがあるので、完全に置き換えるのは難しいでしょう。それに、これまでは Apache を使用していた人も多く、新しいものを作るのに抵抗がありました。最初は、まるで帝都に来たことがないかのように、地下鉄はとても混んでいて、ペースが速かったことを思い出しましたが、実際に来てみると、それほど怖くないことがわかります。

主な理由は、.htaccess ファイルを直接解析できる Apache とは異なり、ユーザーが独自の構成ファイルを変更したからといってホストは Nginx を再起動することができないためです。これは使用に影響します。他のユーザーの。