なぜイベントベースのネットワークアプリケーションは、スレッドアプリケーションよりも本質的に高速なのですか？

Question

私たちはすべてベンチマークを読んで事実を知っています。イベントベースの非同期ネットワークサーバーは、スレッド対応のものよりも高速です。 lighttpdまたはZeusとApacheまたはIISを比較してください。なぜですか？

Answer 1

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

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

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

非ブロッキングIOのGoogleで詳細を確認してください。スレッドプールとの比較もいくつかあります。

（これらのポイントを明確にできる人がいたら、お気軽に）

Answer 2

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

イベントの理由悪いアイデア（高同時実行サーバーの場合）：

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のスレッド化の状態は確実に改善されました。

イベントベースのサーバーのコアを作成することは、適切なプリエンプティブマルチタスクを既にサポートしているOS上で、透過的なコンテキストスイッチングの利点なしに、コードで協調マルチタスク（Windows 3.1スタイル）を再発明することを意味します。これは、通常は命令ポインターによって暗示されるか、スタック変数に格納されるヒープの状態を管理する必要があることを意味します。 （もしあなたの言語がそれらを持っているなら、クロージャはこの痛みを大幅に緩和します。Cでこれをしようとするのはずっと楽ではありません。）

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

イベントベースのアーキテクチャから優れたパフォーマンスを得るのは、特にスループットだけでなく待ち時間を考慮する場合は注意が必要です。 （もちろん、スレッドでも同様に多くの間違いを犯す可能性があります。並行性は依然として困難です。）

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

• 現在サポートする予定のプラットフォームでスレッドはどのように機能しますか？彼らはあなたのボトルネックになるだろうか？
• まだスレッドの実装に問題がある場合：なぜ誰もこれを修正しないのですか？

Answer 3

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

イベントモデルでより複雑なサーバーアプリケーションを正しく開発することは、一般にかなり注意が必要です。スレッドアプリケーションは、作成がはるかに簡単です。これはパフォーマンスではなく決定要因になる可能性があります。

Answer 4

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