IISワーカースレッドとWebアプリケーションスレッド
バックグラウンドスレッドを繰り返し実行する必要があるASP.NET Core Webアプリケーションを維持しています。私はそれが良いデザインではないことを知っていますが、現在私は最小限の努力でその主要な問題を修正しなければなりません。ユーザーのHTTPリクエストをWebサーバーで処理することについて心配する必要があるかどうか、疑問に思います。
質問は簡単ですが、明確な答えが見つかりません。
このようなアプリケーションで作成されるスレッド間の違いは何ですか：
Task.Run(() => { // some parallel job })
およびIISのワーカースレッド？
それらは同じスレッドプールからのものですか、それとも別のプールに存在しますか？
this によると、それはすべて1つのプールです：「ASP.NET Coreはすでに通常のスレッドプールスレッドでアプリのコードを実行しています。」つまり、リクエストを処理するスレッドとバックグラウンドスレッドに個別の最大値はありません。
最大の違いは、IISは、着信要求のためにそれ自体が作成するスレッドを認識していることです。IISは、自分で作成したスレッドを認識していません。
アプリプールがリサイクルされるか、IISがシャットダウンされると、すべてのリクエストの処理が完了するまで待機します。各リクエストに対して作成したスレッドの処理が完了するまで待機します。その後、プロセス。リクエストより長生きするスレッドを作成した場合（たとえば、バックグラウンドスレッドを作成し、クライアントに応答を送信した場合）IISは、スレッドがまだ実行中であることを認識しておらず、プロセス全体をいつでも強制終了できます。
すべてのスレッドが完了するまで応答を返さなければ、その特定の問題は発生しません。
もう1つの問題は、許容されるスレッドの最大数に達する可能性があることです。次に、あらゆる種類の奇妙なパフォーマンスの問題が発生します。ただし、作成するスレッドの数と、受信するHTTPリクエストの数によって異なります。