今日は、Apache httpdおよびnginx Webサーバーの類似点と相違点、長所と短所のより詳細な比較です。私はWeb開発をしていないので、誤解があることを理解してください私の仕事でそれを使用することがあるので私はそれらを理解したいと思います私は私のシステムでnginx + apacheを使いました。この記事の大部分の情報はインターネットから抜粋されたもので、インターネット上に散在するリソースを統合して独自の洞察を追加することだけです。簡単に言うと、Apache httpdとnginxはWebサーバーですが、2つは異なるシナリオに適応します。つまり、2つは異なる問題の解決に焦点を当てています。 Apache httpd：安定した強力な動的リクエスト処理、同時に並行パフォーマンスが低い場合は高いパフォーマンス、より多くのリソースを費やす。 Nginx：高い並行処理能力、静的要求の処理、リバースプロキシ、およびバランスの取れた負荷の処理に優れています。この記事では、apacheとnginxの13の類似点と相違点について詳しく説明します。

1、Apacheと比較したnginxの利点：軽量、Webサービスからの利用、メモリとリソースの削減、同時並行性、nginxの処理要求は非同期のノンブロッキング、apacheはブロッキングタイプ同時に、nginxは、低リソース、低消費電力、高性能、高度なモジュール設計、比較的シンプルなライティングモジュール、活発なコミュニティを維持することができ、さまざまな高性能モジュールが迅速に生産されます。

nginxに対するapacheの利点：書き換え、nginxの書き換えよりも強力なモジュール、多くのモジュール、基本的な考え方はバグが少なく、nginxのバグは比較的安定しています。一般的に、nginxを使用してパフォーマンスを必要とするWebサービスが存在することがその理由です。あなたがパフォーマンスを必要とせず、安定性を求めているのであれば、apacheを使ってください。後者のさまざまな機能モジュールは前者よりも優れて実装されています。たとえば、sslモジュールは前者より優れており、多くの設定可能な項目があります。ここで注意しなければならないのは、epoll（freebsd上のkqueue）ネットワークIOモデルがnginx処理の高性能の根本的な理由であるということですが、静的サービスを提供するのであれば、すべてのケースがepoll勝利ではありません。ファイル、apacheの選択モデルはepollよりも効率的かもしれません。もちろん、これはネットワークIOモデルの原理に基づいた単なる仮説であり、実際のアプリケーションを測定する必要があります。

##ネットワークIOの再利用モデルについては、私は自分では理解できませんが、epidについてBaidu Encyclopediaに説明しました。epollはLinux上での多重化IOインターフェースのselect / pollの拡張版であり、多数の同時接続でプログラムを大幅に改善できます。イベントを待つ前に毎回リスニングするファイルディスクリプタのセットを開発者に再準備させることなく、ファイルディスクリプタセットを再利用して結果を渡すため、アクティブなシステムCPU使用率はごくわずかです。 1つの理由は、イベントを取得するときに、カーネルIOイベントによって非同期的に起こされてReadyキューに追加されたディスクリプタのセットをトラバースする限り、リスニングされているリスナのセット全体をトラバースする必要がないことです。この点から、nginxによって使用されるepollは理論上のselectアルゴリズムよりも効率的であることがわかります（なぜ理論的には、O（N）とO（N ^ 2）アルゴリズムを処理する場合の例を挙げましょう）。データのサイズは1か非常に小さいです、2つは効率の違いを反映できますか？）もう1つはselect IOモデルが各プロセスによって開かれるファイル記述子に制限があるということです、それで私はapache高い同時実行性のパフォーマンスにも影響します。要因です。

2. Webサーバーとして：Apacheと比較して、Nginxはより少ないリソースを使用し、より多くの同時接続をサポートし、そしてより高い効率を達成します。これはNginxを特にウェブホスティングプロバイダーに普及させます。高い接続並行性の場合には、Nginxは、Apacheサーバーの代わりになることができます：Nginxは、米国のWebホスティング事業の所有者がよく選ぶソフトウェアプラットフォームの1つで、Nginxのおかげで最大50,000の同時接続をサポートできます。開発モデルとしてepollとkqueueを選択しましたNginxはロードバランシングサーバーとして機能します：NginxはRailsとPHPプログラムを内部的に直接サポートすることも、HTTPプロキシサーバーとして外部サービスをサポートすることもできます。システムリソースのオーバーヘッドやCPU使用効率はPerlbalよりもはるかに優れていますメールプロキシサーバーとして：Nginxも非常に優れたメールプロキシサーバーです（この製品の最も初期の開発の1つはメールプロキシサーバーでもあります）。 Nginxは非常に単純なインストールで、設定ファイルは非常に単純です（perl構文もサポートします）、非常に少数のサーバのバグ：Nginxの起動は特に簡単で、ほとんどの場合7 * 24で実行できます。数ヶ月間稼働していない再起動する必要がありますソフトウェアのバージョンを中断することなくアップグレードすることもできます。

## nginxはApacheよりも高い同時接続をサポートしていますが（これは最初の点に関連しています。ネットワークIOモデルが異なります。もう1つはnginxが非同期的に要求を処理し、apacheは同期処理です）。各プロセスは要求に対応します。プロセスごとに1つのリクエストを使用するapacheの欠点については後で説明します。

3、Nginxの設定は単純です、Apacheの複合、Nginxの静的処理性能はApacheの3倍以上、PHPのApacheサポートは比較的単純です、Nginxは他のバックエンドと一緒に使う必要があります。

## Nginxは動的処理要求には弱く、それ自身の実装に関連したいのですが、PHPや他の言語をサポートするために他のモジュールと組み合わせる必要があります。メッセージ案内〜

4、コアの違いは、Apacheは同期マルチプロセスモデルであり、接続はプロセスに対応し、nginxは非同期であり、複数の接続（10,000レベル）はプロセスに対応することができます。

##リクエストを要求するためのモデルが異なると、2つのポイントに直接つながります：a> nginxは反並行性の能力が非常に高いb> nginxはリクエストが非常に大きい場合apacheプロセスとリクエストが一対一で対応するためリソースが少ないリソース要件は大きく、プロセス作成コストは高くつきます。しかし今改良をしたようです、preforkは必要に応じていくつかのプロセスをあらかじめ作成することができます、これはスレッドプールの概念にいくぶん似ています。

5、静的ファイルを処理するnginxは良い、少ないメモリですが、間違いなくapacheが現在の主流であり、豊富な機能がたくさんありますので、もちろん、nginxが需要に適していると判断できれば、nginxを使うほうが経済的です。方法です。

##これは上記の点に関連しているべきです：nginxはepoll IO再利用モデルを使用します;リクエストは非同期的に処理されます;スレッドとリクエストは一対多の関係です。

6、過去の個人的な使用から、nginxの負荷容量はapacheよりはるかに高いです。最新のサーバーもnginxに変更されました。そしてnginxは設定を変更することができます問題がない設定をテストすることができます、設定が間違っていることがわかったときにapacheが再起動します、それは非常にクラッシュします、変更は非常に用心深いでしょう、フロントエンドnginx反並行性、バックエンドapacheクラスタ協力は悪くありません。

##ここでは、主にこれに焦点を当てます。nginx+ apacheの組み合わせ使用。 Nginxは反並行性、ロードバランシング、静的ファイルキャッシュを担当し、バックエンドはapacheを使用して動的なリクエストを処理します。

7、動的要求を処理するnginxはチキンリブ、行うべきapacheへの一般的な動的要求、静的および逆方向にのみ適したnginxです。

## nginx動的な要求に対処することがチキンリブの理由です、誰が原理を説明するのを助けることができますか？ PHPの言語サポートが十分ではないからでしょうか。 nginxに適しているのは静的リクエストとリバースプロキシです。簡単に言えば、クライアントはターゲットマシンとしてnginxサーバを使用してリクエストをnginxマシンに送信しますが、nginxマシンに関しては、クライアントが必要とするリソースはクライアントから取得されます。エージェント、フォワードプロキシではターゲットマシンにアクセスできません。リクエストをプロキシマシンに送信してから、必要なリソースを自分の名前で取得するためです。

8、私の個人的な経験から、nginxは非常に良いフロントエンドサーバーです、ロードパフォーマンスは非常に良いです、古いランで開いているnginxは、努力なしで10,000静的ファイル要求をシミュレートするためにwebbenchを使います。 phpや他の言語へのApacheのサポートはとても良いです、加えてapacheは強力なサポートネットワークを持ち、開発時間はnginxより長く、バグはありますがApacheはマルチコア処理負荷の欠点をサポートしません、フロントエンド、バックエンドとしてnginxの使用を推奨Apacheを使用してください。大規模Webサイトでは、nginx自己生成クラスタ機能の使用を推奨しています

##これはまだnginx + apacheが良い選択であると言っています。

1. Nginx自体はリバースプロキシサーバーです2. Nginxは7層のロードバランシングをサポートします;もちろん、NginxはApacheよりも高い同時実行性をサポートする可能性がありますが、NetCraftの統計によると2011年4月現在、Apacheは62.71％を保持していますが、Nginxは7.35％です。そのため、Aapcheは、成熟したテクノロジと開発コミュニティも非常に優れたパフォーマンスを誇るため、依然としてほとんどの企業で最初です。 。

## Apacheは早く登場し、人々は最初は選択しませんでした、そしてWebサイトの小さなプレッシャーもApacheによるリクエストプレッシャーに対処するのに十分であるので、2つの市場シェアの間にギャップがあります。

10. Webサーバーに対するニーズによって、選択が決まります。静的ファイル処理、PHP-CGIサポート、リバースプロキシ機能、フロントエンドキャッシュ、メンテナンス接続性など、ほとんどの場合、nginxはAPACHEより優れています。 Apache + PHP（prefork）モードでは、PHPの処理が遅い場合やフロントエンドのプレッシャーが高い場合、Apacheプロセスの数が急増しているためサービスが拒否されます。

##アパッチの欠陥、耐圧力は良くありません、そしてスレッドの数が急上昇するので、リソースの需要も大きいです

11、あなたはnginxのluaモジュールを見ることができます：https：//github.com/chaoslaw…apacheより多くのnginxのモジュール、あなたは直接Apacheを達成するためにluaを使用することができます、なぜですか？ほとんどの人は、nginxにアップデートしたり、新しいことを学ぶのが面倒です。
## …

12、nginxのために、私はその設定ファイルが書くのがとても簡単で、規則的な設定がフロントエンドの応答サーバーのために非常に適したものを単純で効率的な、低い資源消費、強力なプロキシの多くにします

##見て、nginxの設定ファイルは確かにもっと簡潔で理解しやすいです。

13、Apacheは処理能力に利点があり、Nginxの同時実行性が向上し、CPUメモリの使用量が少なく、書き換えが頻繁であれば、それでもApacheです。
## rewriteこれはあまりよく理解されていませんが、言っても過言ではありません