イベントMPMはNginxとまったく同じ設計ではありませんが、キープアライブをより持続可能にし、静的ファイルをより高速に送信するように明確に設計されています。私の理解では、イベントMPMは、次の理由で少し誤解されています。
残念ながら、Apacheは市場シェアを失い続けており、ほとんどのベンチマークはイベントMPMを酷評しています。ベンチマークに欠陥がありますか、それともイベントMPMがNginxに対して本当に不十分ですか?これらの制限があっても、通常のトラフィック(悪意のない)や小さなファイルでは、Nginxとある程度競合するはずです。たとえば、遅い接続でphp-fpmを介してPHPで生成されたドキュメントを提供することは、ドキュメントがバッファリングされ(sslおよびgzipされた場合でも)非同期に送信されるため、競争力があるはずです。圧縮を使用するかどうかに関係なく、SSL接続と非SSL接続の両方が、そのようなワークロードでNginxの場合と有意義に異なる動作をするべきではありません。
では、なぜそれがさまざまなベンチマークで輝かないのでしょうか?どうしたんだ?または、ベンチマークの何が問題になっていますか?主要なサイトは、それを実行できる権威への訴えとしてそれを使用していますか?
イベントMPMを使用するApacheは、ワーカーMPMを使用するApacheの前にあるイベント駆動型HTTPプロキシ(nginx、varnish、haproxy)と(非常に)ほぼ同等であるため、nginxよりも低速です。イベントisワーカーですが、イベントMPMのスレッドは、新しい接続をその存続期間中スレッドに渡すのではなく、接続をセカンダリスレッドに渡します。セカンダリスレッドは、接続をキューにプッシュするか、キープアライブの場合は閉じます。オフまたは期限切れです。
ワーカーに対するイベントの本当の利点は、リソースの使用量です。 1,000の同時接続を維持する必要がある場合、ワーカーMPMには1,000のスレッドが必要ですが、イベントMPMは、イベントキューで管理される100のアクティブスレッドと900のアイドル接続で処理できます。イベントMPMは、その仮定でワーカーMPMのリソースの一部を使用しますが、欠点はまだあります。これらの各要求は、カーネルによってスケジュールされる必要がある個別のスレッドによって処理されるため、次のコストが発生します。コンテキストの切り替え。
一方、イベントモデル自体をスケジューラーとして使用するnginxがあります。 Nginxは、次の接続に進む前に、各接続で可能な限り多くの作業を処理するだけです。追加のコンテキスト切り替えは必要ありません。
イベントMPMが本当に輝いている1つのユースケースは、Apacheで重いアプリケーションを実行しているセットアップを処理し、キープアライブ中にアイドル状態になっているスレッドのリソースを節約するために、プロキシ(nginxなど)をデプロイすることです。 Apacheの前で。フロントエンドが他の目的(静的コンテンツ、他のサーバーへのプロキシなど)を果たさなかった場合、イベントMPMはそのユースケースを処理します美しくそしてプロキシの必要性を排除します。
私にとって、支配的な運用上の違いは、イベントの場合です。
そのため、nginx(またはApache Traffic Serverまたは最新の商用/高性能プロキシ)のような非常に大容量のサーバーが通常先行します。
IMOあなたの質問の箇条書きは少し外れています、SSLとdeflateはどちらもスケーラビリティの問題に実際には寄与しないか、httpdを従来のAPI保証に結び付けさえしないため、ここでの違いにはあまり寄与していません。リクエストまたは接続のライフサイクル。これらのようなフィルター(vs.ハンドラー、または低レベルI/Oを担当するコアフィルター)は、おそらく処理モデルに関連するものの中で最も少ないものです。
しかし、最も極端なワークロードまたは極端に制約されたシステムを除いて、比較すると、パフォーマンスがそれほど悪いとは思いません。私が見たベンチマークのほとんどは、何らかの理由で非常に質の悪いものです。
今日のWebサーバーと呼ばれるものを、より洗練されたアプリケーションサーバー(Java EE、PHPなど)のプロキシにしたいと考えている人が多いと思います。APIの手荷物なしでI/Oを最も効率的に移動するように設計されたサーバーにはEdgeが搭載されます。 。