5

私たちは皆、ベンチマークを読み、その事実を知っています。イベントベースの非同期ネットワーク サーバーは、スレッド化されたものよりも高速です。lighttpd または Zeus 対 Apache または IIS を考えてみてください。何故ですか？

4

4 に答える 4

5

イベントベースとスレッドベースは問題ではないと思います-それはノンブロッキングの多重化I / O、選択可能なソケット、ソリューションとスレッドプールソリューションです。

最初のケースでは、それを使用しているものに関係なく、入ってくるすべての入力を処理しているため、読み取りがブロックされることはなく、単一の「リスナー」です。単一のリスナー スレッドは、接続ごとに 1 つではなく、さまざまなタイプのワーカー スレッドにデータを渡します。繰り返しになりますが、データの書き込みをブロックすることはありません。そのため、データ ハンドラーはそれを個別に実行できます。このソリューションはほとんどが IO の読み取り/書き込みであるため、多くの CPU 時間を占有することはありません。したがって、アプリケーションはそれを利用して、必要なことを何でも行うことができます。

スレッドプールソリューションでは、個々のスレッドが各接続を処理するため、コンテキストスイッチのインとアウトの時間を共有する必要があります-それぞれが「リッスン」します。このソリューションでは、CPU + IO 操作は同じスレッド内にあり、タイム スライスを取得します。そのため、従来は CPU 時間を使用せずに実行できたスレッドごとの IO 操作が完了するのを待つことになります (ブロック)。

詳細については、ノンブロッキング IO の Google を参照してください。また、スレッド プールとの比較もいくつか見つけることができます。

（これらの点を明確にできる人がいれば、遠慮なく）

于 2008-11-14T13:57:41.037 に答える
3

イベント駆動型アプリケーションは、本質的に高速ではありません。

イベントが悪い考えである理由から(高同時実行サーバーの場合) :

We examine the claimed strengths of events over threads and show that the
weaknesses of threads are artifacts of specific threading implementations
and not inherent to the threading paradigm. As evidence, we present a
user-level thread package that scales to 100,000 threads and achieves
excellent performance in a web server.

これは 2003 年のことです。確かに、最新の OS のスレッド化の状態はそれ以来改善されています。

イベントベースのサーバーのコアを作成するということは、コード内で協調マルチタスク (Windows 3.1 スタイル) を再発明することを意味します。これは、適切なプリエンプティブ マルチタスキングを既にサポートしている OS 上で、透過的なコンテキスト切り替えの利点がない場合がほとんどです。これは、通常は命令ポインターによって暗示されるか、スタック変数に格納されるヒープ上の状態を管理する必要があることを意味します。(言語にクロージャがある場合、クロージャはこの問題を大幅に軽減します。これを C でやろうとすると、あまり楽しくありません。)

これはまた、協調的なマルチタスクが意味するすべての警告を得るということでもあります。イベント ハンドラーの 1 つが何らかの理由で実行に時間がかかる場合、そのイベント スレッドが停止します。まったく関係のないリクエストは遅れます。これを回避するには、長時間の CPU 負担の操作でさえ、別の場所に送信する必要があります。同時実行性の高いサーバーのコアについて話している場合、「長時間の操作」は相対的な用語であり、1 秒あたり 100,000 の要求を処理すると予想されるサーバーのマイクロ秒のオーダーです。仮想メモリ システムがディスクからページをプルする必要がなくなることを願っています。

イベントベースのアーキテクチャから優れたパフォーマンスを得るには、特にスループットだけでなくレイテンシを考慮する場合は注意が必要です。(もちろん、スレッドでも起こりうる間違いはたくさんあります。同時実行は依然として困難です。)

新しいサーバー アプリケーションの作成者に対するいくつかの重要な質問:

  • 現在サポートする予定のプラットフォームで、スレッドはどのように機能しますか? それらはあなたのボトルネックになるでしょうか？
  • あなたがまだ悪いスレッドの実装で立ち往生しているなら: なぜ誰もこれを修正しないのですか?
于 2012-06-29T19:05:50.013 に答える
1

それは本当にあなたが何をしているかに依存します。イベントベースのプログラミングは、重要なアプリケーションにとって確かに扱いにくいものです。Web サーバーであることは、よく理解されている非常に些細な問題であり、イベント駆動モデルとスレッド モデルの両方が最新の OS でうまく機能します。

イベント モデルでより複雑なサーバー アプリケーションを適切に開発することは、一般的に非常に注意が必要です。スレッド化されたアプリケーションは、はるかに簡単に記述できます。これはパフォーマンスよりも決定的な要因かもしれません。

于 2008-11-14T14:05:15.063 に答える
0

それは実際にはスレッドに関するものではありません。これは、スレッドが要求を処理するために使用される方法に関するものです。lighttpd のようなものでは、イベントを介して複数の接続にサービスを提供する単一のスレッドがあります。古いバージョンの apache では、接続ごとにプロセスがあり、プロセスは着信データで起動したため、多くのリクエストがあると非常に多くの数になりました。ただし、MPM では apache はイベント ベースであり、apache MPM eventも参照してください。

于 2008-11-14T13:59:16.650 に答える