22

Event MPM は Nginx とまったく同じ設計ではありませんが、キープアライブをより持続可能にし、静的ファイルの送信を高速化するように明確に設計されています。私の理解では、次の理由により、イベント MPM は少し間違った名前です。

  1. 接続はkqueue/epollに渡されますが、
  2. mod_gzip や mod_ssl などの特定の非常に重要なモジュールは、応答が完了するまでスレッドをブロック/消費します。
  3. これは大きなファイルでは問題になりますが、PHP で生成された HTML ドキュメントなどではおそらく問題になりません。

残念なことに、Apache は市場シェアを失い続けており、ほとんどのベンチマークはイベント MPM に悪影響を及ぼすものです。ベンチマークに欠陥がありますか、それともイベント MPM は実際に Nginx に対してあまり効果がありませんか? これらの制限があっても、通常のトラフィック (悪意のない) と小さなファイルの下では、Nginx とある程度競合するはずです。たとえば、低速接続で php-fpm を介して PHP で生成されたドキュメントを競合的に提供する必要があります。これは、ドキュメントが (ssl および gzip されている場合でも) バッファリングされ、非同期で送信されるためです。圧縮を使用するかどうかに関係なく、SSL 接続と非 SSL 接続の両方が、そのようなワークロードで Nginx と異なる意味で動作するべきではありません。

では、なぜさまざまなベンチマークで輝いていないのでしょうか? どうしたの？または、ベンチマークの何が問題になっていますか? それが実行できる権限へのアピールとして、主要なサイトはそれを使用していますか?

4

2 に答える 2

18

イベントMPMを使用したApacheは、ワーカーMPMを使用したApacheの前にあるイベント駆動型HTTPプロキシ（nginx、varnish、haproxy）と（非常に）ほぼ同等であるため、nginxよりも遅くなります。イベントはワーカーですが、イベント MPM のスレッドは、新しい接続をその存続期間中スレッドに渡すのではなく、セカンダリ スレッドに接続を渡します。セカンダリ スレッドは、キューにプッシュするか、キープアライブがオフまたは期限切れの場合は閉じます。

ワーカーに対するイベントの本当の利点は、リソースの使用です。1,000 の同時接続を維持する必要がある場合、ワーカー MPM には 1,000 のスレッドが必要ですが、イベント MPM は 100 のアクティブ スレッドと 900 のアイドル接続をイベント キューで管理することで対処できます。イベント MPM は、その仮説ではワーカー MPM のリソースの一部を使用しますが、欠点は依然として存在します。これらの要求のそれぞれは、カーネルによってスケジュールされる必要がある個別のスレッドによって処理されるため、次のコストが発生します。コンテキストの切り替え。

一方、イベント モデル自体をスケジューラとして使用する nginx があります。Nginx は、次の接続に移る前に、各接続でできるだけ多くの作業を処理します。追加のコンテキスト切り替えは必要ありません。

イベント MPM が本当に役立つ 1 つの使用例は、Apache で重いアプリケーションを実行しているセットアップを処理し、キープアライブ中にアイドル状態のスレッドのリソースを節約するために、プロキシ (nginx など) を展開することです。アパッチ前。フロント エンドが他の目的を果たさない場合 (静的コンテンツ、他のサーバーへのプロキシなど)、イベント MPM はそのユース ケースを美しく処理し、プロキシの必要性を排除します。

于 2015-01-14T21:40:55.527 に答える
7

私にとって、支配的な運用上の違いは次のとおりです。

  • ハンドラー (応答の生成を担当するプラグイン) は同期的です。それらが計算または I/O を実行している場合、それらはスレッドを結び付けます。
  • これらの同期要求の非常に多くをサポートするためにマルチスレッド化されているため、コアはクロススレッド ロックを使用して主要なデータ構造を保護する必要があります。

そのため、nginx (または Apache Traffic Server または最新の商用/高性能プロキシ) のような非常に大量のサーバーが通常先行します。

IMOあなたの質問の箇条書きは少し的外れです。SSLとdeflateは、どちらもスケーラビリティの問題に実際には寄与しないフィルターであり、httpdを従来のAPI保証に結びつけることさえないため、ここでの違いにあまり貢献していません。リクエストまたは接続のライフサイクル。このようなフィルター (対ハンドラー、または低レベルの I/O を担当するコア フィルター) は、おそらく処理モデルに関連付けられているものの中で最も小さいものです。

しかし、最も極端なワークロードまたは非常に制約のあるシステムを除いて、比較するとパフォーマンスがそれほど悪いとは思いません. 私が見たベンチマークのほとんどは、何らかの理由で非常に質が悪いものでした。

多くの人は、現在 Web サーバーと呼んでいるものを、より洗練されたアプリケーション サーバー (Java EE、PHP など) へのプロキシとして使用することを望んでおり、API バゲージなしで I/O を最も効率的に移動するように設計されたサーバーが優位に立つと考えています。 .

于 2015-01-13T01:46:43.730 に答える