c# - タスク並列ライブラリと IIS ワーカー スレッド?

Question

いくつかの計算集約的なタスクに Task Parallel Library を使用したいのですが、IIS がワーカー スレッドを作成するためのオーバーヘッドが大きいと同僚から言われました。

Task.Factory.StartNew()... を 100 回呼び出すと、何が行われるのかよくわかりません。IIS はこれをどのように処理しますか? これは大きなリスクですか、それともアプリケーションにとってこれを非常に有益にする方法はありますか?

Answer 1

最初のタスク != スレッド。いくつかのスレッド (既にプールされている) によって処理されている多くのタスクがある場合があります。

原則として、私は Web サーバーで実行時間の長いプロセスを実行することに反対です。長時間実行されるジョブを維持するには多くの問題があり、Web サーバーのスケーラビリティが低下する傾向があります。特に、長時間実行され、CPU を集中的に使用するジョブを並列化する場合はそうです。マシン上で実行するスレッドの最適な数は、「論理」コアの数と同じであることを忘れないでください。余分なスレッドを作成することは避けたいと考えています (管理された各スレッドは、オーバーヘッドでメガのようなものを消費します)。CPU を集中的に使用するジョブを実行すると、リクエストの処理に CPU 時間がかかります。

私の意見では、Web サーバーで tpl を使用する最良の方法は、リクエストをできるだけブロックしないようにすることを目標に使用することです。これにより、最小数のリクエストで最大数のリクエストを処理できます。スレッド。多くの人が、高度に非同期のリクエスト処理によって得られる追加のスケールは、追加の複雑さに値しないという決定を下すことに注意してください。あなたの特定のケースに依存します。

要するに、Web サーバーで実行時間の長い CPU バインド タスクを多数実行すると、スケーラビリティが危険にさらされます。タスク、スレッド、backgroundworkers、またはスレッドプールを使用しているかどうかは問題ではありません。要するに同じことです。

Answer 2

抽象化の優れた点の 1 つは、Taskスレッドの作成を抽象化することです。これが意味することは、TPL (実際にはThreadPool) が実際のスレッドの最適な量を決定できるということです。このため、100 をTask作成しても 100 は作成されない可能性が高くなりますThread。そのため、 を作成するオーバーヘッドについて心配する必要はありませんThread。

しかし、それはTask彼らがどのようなものであるかにもよります。Task長い IO バウンド操作を実行する100の s があり、ほとんどの場合それらがブロックされる場合、それは TPL の適切な使用法ではなく、コードは非常に非効率的になります (実際には 100 Threads になる可能性があります)。

一方、100 個の CPU バウンドで比較的短いTasks がある場合、それが TPL のスイート スポットであり、効率が高くなります。

効率が本当に気になる場合は、Tasks にはオーバーヘッドがあることも知っておく必要があります。そのため、場合によっては、複数の を 1 つの大きなものにマージTaskして、オーバーヘッドを小さくすることが理にかなっている場合があります。または、すでにそれを行っているものを使用することもできます:Parallel.ForEachまたはParallel.For、それらがユースケースに適合する場合。Task別の利点として、それらを使用するコードは、手動で s を使用するよりも読みやすくなります。

Answer 3

スレッド化のオーバーヘッドは、どのホストでも同じです。少なくともパフォーマンスに関しては、IIS とは何の関係もありません。

他にも懸念事項があります。たとえば、アプリケーションのシャットダウン時に、ユーザー スレッドは乱暴に中止されます。

Answer 4

この作業を処理するサービスを作成するだけではどうですか? スケーリングの点ではるかに優れており、その作業単位をうまく分離できます...作業が計算に縛られている場合でも.

Thread Pool/BackgroundWorker/Thread私の意見では、ASP.NETでは使用しないでください。あなたの場合、TPL単純にスレッドプールをラップします。通常、それは価値があるよりも面倒です。