http - イベント ループとマルチスレッド ブロッキング IO

Question

サーバーアーキテクチャに関するコメントを読んでいました。

http://news.ycombinator.com/item?id=520077

このコメントで、その人は 3 つのことを言います。

1. イベント ループは、アクティビティの少ない多数の接続で真に優れていることが何度も示されています。
2. これに対し、スレッドまたはプロセスを使用したブロッキング IO モデルは、イベント ループと比較して、リクエストごとのレイテンシを削減することが何度も示されています。
3. 負荷の軽いシステムでは、違いは区別できません。負荷がかかると、ほとんどのイベント ループは速度を落とすことを選択し、ほとんどのブロッキング モデルは負荷を減らすことを選択します。

これらのいずれかが真実ですか?

また、「イベントが悪い考えである理由 (高同時実行サーバーの場合)」というタイトルの別の記事もここにあります。

http://www.usenix.org/events/hotos03/tech/vonbehren.html

Answer 1

通常、アプリケーションが数百万の接続を処理することが予想される場合は、マルチスレッド パラダイムとイベント ベースを組み合わせることができます。

1. まず、N == マシン上のコア/プロセッサの数である N 個のスレッドとして生成します。各スレッドには、処理するはずの非同期ソケットのリストがあります。
2. 次に、アクセプターからの新しい接続ごとに、新しいソケットを最も少ないソケットを持つスレッドに「負荷分散」します。
3. 各スレッド内で、すべてのソケットにイベントベースのモデルを使用して、各スレッドが実際に複数のソケットを「同時に」処理できるようにします。

このアプローチにより、

1. 百万のスレッドを生成することはありません。システムが処理できる数だけ持っています。
2. シングルコアではなく、マルチコアのイベントベースを利用します。

Answer 2

「低アクティビティ」の意味はわかりませんが、主な要因は、各リクエストを処理するために実際にどれだけの作業を行う必要があるかということだと思います。シングルスレッドのイベントループを想定すると、現在のリクエストを処理している間、他のクライアントはリクエストを処理できません。各リクエストを処理するために多くのことを行う必要がある場合（「ロット」はかなりのCPUや時間を要するものを意味します）、マシンが実際に効率的にマルチタスクを実行できると仮定します（時間がかかることは共有を待つことを意味しません）単一のCPUマシンなどのリソース）、マルチタスクによってパフォーマンスが向上します。マルチタスクはマルチスレッドブロッキングモデルである可能性がありますが、着信要求を収集するシングルタスクイベントループである可能性もあります。

OSがアプリの外部で効率的に処理するため、クライアントとの接続が遅いことはそれほど重要ではないと思います（最初にリクエストを開始したクライアントとの複数のラウンドトリップのイベントループをブロックしないと仮定します） 、しかし私はこれを自分でテストしていません。