asp.net - IHttpHandler と IHttpAsyncHandler を使用したスレッドプール VS の使用

Question

IHttpAsyncHandler は、要求を非同期的に実行することを意味します。

スレッド プールを使用すると、非同期で実行することもできます。

したがって、関数 (Comet、long poll など) を実装する場合、IHttpHandler でスレッド プールを使用する場合と IHttpAsyncHandler を使用する場合のどちらが優れていますか?

編集: @Jon Skeet: 辛抱強い返信ありがとうございます。結論を言いましょう。IHttpHandler で delegate.BeginInvoke を使用すると、プールされたスレッドで何が起こっても、要求を処理する「メイン スレッド」は要求が終了するまで回転し続けます。IHttpAsyncHandler を使用すると、リクエストを処理する「メイン スレッド」が BeginProcessRequest を呼び出し、その後、(他のリクエストを処理するために) 解放されます。BeginProcessRequest メソッドは非同期で何かを行います。非同期アクションが終了すると、EndProcessRequest メソッドが呼び出されます (または、「メイン スレッド」が EndProcessRequest 関数を呼び出して現在の要求を終了すると言えます)。

以上が私の考えですが、よろしいでしょうか？

Answer 1

違いは、真の非同期モデルでは、リクエストごとにスレッドがまったく必要ないことです。リクエストごとにスレッドがある場合、それがスレッド プール上にあるかどうかに関係なく、多数の接続を処理する必要があります (ロング ポーリングなどで必要になるため)。

10 万のクライアントがあり、それぞれのロング ポーリングがあるとします。本当に 100,000 スレッドが必要ですか? (ヒント: 十分なメモリがあるとは思えません...)

真の非同期性により、リクエストごとに専用のスレッドを用意しなくても、リクエストを終了することでイベントに対応できます。C# 5 と .NET 4.5 では、 を使用するよりも簡単な方法もありIHttpAsyncHandlerます。await何を達成しようとしているかによって異なりますが、WCF と MVC の両方に、式などを使用して非同期メソッドを記述できる非同期指向のアプローチがあります。タイマー、またはおそらく一部の IO の完了) を実行すると、膨大な数の同時接続を管理できます。

編集: さらに質問に答えるには: はい、 just を使用する場合、呼び出しが完了したときにIHttpHandler要求を完了する必要ProcessRequestがあります。「ぶら下がった」ままにしておくことはできません...が呼び出されるIHttpAsyncHandlerまで、リクエストを進行中のままにすることができます。EndProcessRequestただし、これは非常に古いインターフェイスであることを忘れないでください。明確に文書化されているわけではありません。特に .NET 4.5 と C# 5.進行中のリクエストを持つことができるという主なポイントは、特定のスレッドが関連付けられていなくても保持されます。