トラフィックの多いシナリオでのASP.NETでのThreadPool.QueueUserWorkItemの使用

ASP.NETでも、短期間のバックグラウンドタスク（クリティカルでないとしましょう）にThreadPoolを使用することがベストプラクティスであると常に考えていましたが、そうでない場合はこの記事に出くわしました。引数は、ASP.NET関連の要求を処理するためにThreadPoolを残すべきであるということです。

これが、これまでに小さな非同期タスクを実行してきた方法です。

ThreadPool.QueueUserWorkItem(s => PostLog(logEvent))

そして、記事は代わりに明示的にスレッドを作成することを提案しています：

new Thread(() => PostLog(logEvent)){ IsBackground = true }.Start()

最初の方法には管理と制限があるという利点がありますが、バックグラウンドタスクがASP.NETリクエストハンドラーを使用してスレッドを争っている可能性があります（記事が正しい場合）。2番目のメソッドはThreadPoolを解放しますが、制限がなくなるため、リソースを使いすぎる可能性があります。

だから私の質問は、記事のアドバイスは正しいですか？

サイトのトラフィックが多すぎてThreadPoolがいっぱいになっている場合は、帯域外に移行することをお勧めします。または、完全なThreadPoolはとにかくリソースの制限に達していることを意味します。独自のスレッドを開始しようとすべきではありませんか？

明確化：私は、別のプロセスを必要とする高価な作業項目ではなく、重要ではない小さな非同期タスク（たとえば、リモートロギング）の範囲で質問しているだけです（この場合、より堅牢なソリューションが必要になることに同意します）。

ここでの他の答えは最も重要なポイントを省いているようです：

低負荷のサイトでCPUを集中的に使用する操作を並列化して高速に実行しない限り、ワーカースレッドを使用してもまったく意味がありません。

これは、によって作成された空きスレッドと、リクエストに応答するのnew Thread(...)ワーカースレッドの両方ThreadPoolにQueueUserWorkItem当てはまります。

はい、そうです。あまりにも多くの作業項目をキューに入れることThreadPoolにより、ASP.NETプロセスでが不足する可能性があります。ASP.NETがそれ以上のリクエストを処理するのを防ぎます。記事の情報はその点で正確です。と同じスレッドプールがQueueUserWorkItem要求の処理にも使用されます。

しかし、実際にこの飢餓を引き起こすのに十分な数の作業項目をキューに入れている場合は、スレッドプールを枯渇させる必要があります。文字通り何百ものCPU集中型の操作を同時に実行している場合、マシンが既に過負荷になっているときに、ASP.NET要求を処理するために別のワーカースレッドを使用するとどのようなメリットがありますか？この状況に陥った場合は、完全に再設計する必要があります！

ほとんどの場合、マルチスレッドコードがASP.NETで不適切に使用されているのを見たり聞いたりしますが、これはCPUを集中的に使用する作業をキューイングするためのものではありません。I / Oバウンドの作業をキューに入れるためのものです。また、I / O作業を行う場合は、I / Oスレッド（I / O完了ポート）を使用する必要があります。

具体的には、使用しているライブラリクラスがサポートする非同期コールバックを使用する必要があります。これらのメソッドは常に非常に明確にラベル付けされています。彼らは言葉で始まりBeginとEnd。同様にStream.BeginRead、Socket.BeginConnect、WebRequest.BeginGetResponse、など。

これらのメソッドはを使用しますがThreadPool、ASP.NET要求に干渉しない IOCPを使用します。これらは、I / Oシステムからの割り込み信号によって「起動」できる特殊な軽量スレッドです。また、ASP.NETアプリケーションでは、通常、ワーカースレッドごとに1つのI / Oスレッドがあるため、すべての単一の要求で1つの非同期操作をキューに入れることができます。これは文字通り数百の非同期操作であり、パフォーマンスの大幅な低下はありません（I / Oサブシステムが維持できると仮定）それはあなたが今までに必要とするよりもはるかに多いです。

非同期デリゲートはこの方法では機能しないことに注意してください-と同様に、ワーカースレッドが使用されますThreadPool.QueueUserWorkItem。これを実行できるのは、.NET Frameworkライブラリクラスの組み込みの非同期メソッドだけです。あなたは自分でそれを行うことができますが、それは複雑で少し危険であり、おそらくこの議論の範囲を超えています。

私の意見では、この質問に対する最良の答えは、ASP.NETのまたはバックグラウンドインスタンスを使用しないことThreadPool Threadです。これは、Windowsフォームアプリケーションでスレッドを起動するようなものではなく、UIの応答性を維持するためにスレッドを起動して、その効率を気にしません。ASP.NETでは、あなたの懸念があり、スループット、およびこれらすべてのワーカースレッド上のすべてのそのコンテキストの切り替えは絶対にしようとしている殺すあなたが使用するかどうか、あなたのスループットThreadPoolかを。

ASP.NETでスレッドコードを作成している場合は、既存の非同期メソッドを使用するようにコードを書き直すことができるかどうかを検討し、それができない場合は、本当に本当にコードが必要かどうかを検討してください。バックグラウンドスレッドで実行します。ほとんどの場合、複雑さを追加して正味のメリットは得られないでしょう。

MicrosoftのASP.NETチームのThomas Marquadtによると、ASP.NET ThreadPool（QueueUserWorkItem）を使用しても安全です。

記事から：

Q）ASP.NETアプリケーションがCLR ThreadPoolスレッドを使用する場合、CLR ThreadPoolも使用して要求を実行するASP.NETを枯渇させないのですか？ ..

A）まとめると、ASP.NETでスレッドが不足することを心配する必要はありません。問題が発生したと思われる場合は、お知らせください。問題を解決します。

Q）自分のスレッド（新しいスレッド）を作成する必要がありますか？ASP.NETはCLR ThreadPoolを使用するため、これは適切ではありません。

A）しないでください。または別の言い方をすると、いいえ!!! あなたが本当に賢いなら-私よりずっと賢いなら-あなたはあなた自身のスレッドを作成することができます。そうでなければ、それについて考えさえしないでください。新しいスレッドを頻繁に作成してはならない理由をいくつか次に示します。

1. QueueUserWorkItemに比べて非常に高価です...ところで、CLRよりも優れたThreadPoolを記述できる場合は、Microsoftでの仕事に応募することをお勧めします。

ウェブサイトはスポーンスレッドを回避するべきではありません。

通常は、この機能をWindowsサービスに移動してから通信します（MSMQを使用して通信します）。

-編集

ここで実装について説明しました：ASP.NET MVC Webアプリケーションでのキューベースのバックグラウンド処理

-編集

これがスレッドだけではない理由をさらに詳しく説明します。

MSMQを使用すると、別のサーバーと通信できます。マシン間でキューに書き込むことができるため、何らかの理由でバックグラウンドタスクがメインサーバーのリソースを使いすぎていると判断した場合は、簡単にシフトできます。

また、実行しようとしたタスク（メールの送信など）をバッチ処理することもできます。

ASP.NETでの高速で優先度の低い非同期作業の一般的な方法は、特にリソースが制限されているトラフィック量の多いシナリオでは、.NETスレッドプールを使用することだと思います。

また、スレッド化の実装は隠されています。独自のスレッドの生成を開始する場合は、それらも適切に管理する必要があります。あなたがそれを行うことができなかったとは言わないが、なぜその車輪を再発明するのか？

パフォーマンスが問題になり、スレッドプールが制限要因である（データベース接続、送信ネットワーク接続、メモリ、ページタイムアウトなどではない）ことを確認できる場合は、スレッドプールの構成を調整して、より多くのワーカースレッド、より高いキューリクエストを許可します、など

パフォーマンスの問題がない場合、新しいスレッドを生成してASP.NET要求キューとの競合を減らすことは、古典的な時期尚早の最適化です。

理想的には、ロギング操作を実行するために別のスレッドを使用する必要はないでしょう-元のスレッドが操作をできるだけ早く完了できるようにするだけで、MSMQと別のコンシューマスレッド/プロセスが画面に入ります。これは実装がより重く、より多くの作業であることに同意しますが、ここでの耐久性は本当に必要です。共有されたメモリ内キューの揮発性はすぐに使い果たされます。

QueueUserWorkItemを使用し、ペストを回避するように新しいスレッドを作成しないでください。ASP.NETは同じThreadPoolを使用しているため、ASP.NETが枯渇しない理由を説明するビジュアルについて、ボウリングのピンや剣などを飛行中に2本の手で操作する熟練したジャグラーを想像してください。独自のスレッドの作成が悪い理由を視覚的に示すために、ラッシュアワーでシアトルで何が起きるかを想像してください。高速道路への入り口ランプを頻繁に使用すると、ライトを使用して入り口の数を数秒ごとに1つに制限する代わりに、車両がすぐに通行できます。 。最後に、詳細な説明については、このリンクを参照してください：

http://blogs.msdn.com/tmarq/archive/2010/04/14/performing-asynchronous-work-or-tasks-in-asp-net-applications.aspx

ありがとう、トーマス

その記事は正しくありません。ASP.NETには、ASP.NET要求を処理するための独自のスレッドプール、マネージワーカースレッドがあります。このプールは通常数百のスレッドであり、プロセッサーのより小さな倍数であるThreadPoolプールとは別です。

ASP.NETでThreadPoolを使用しても、ASP.NETワーカースレッドに干渉しません。ThreadPoolの使用は問題ありません。

メッセージをログに記録し、プロデューサー/コンシューマーパターンを使用してログメッセージをそのスレッドに渡す単一のスレッドを設定することも可能です。その場合、スレッドは存続期間が長いため、ロギングを実行するために単一の新しいスレッドを作成する必要があります。

すべてのメッセージに新しいスレッドを使用することは間違いなくやり過ぎです。

ロギングについてのみ話している場合の別の代替手段は、log4netのようなライブラリーを使用することです。別のスレッドでログを処理し、そのシナリオで発生する可能性があるすべてのコンテキストの問題を処理します。

私は記事が間違っていると思います。大きな.NETショップを運営している場合は、ThreadPoolドキュメントの1つのステートメントに基づいて、複数のアプリおよび複数のWebサイトにわたって（個別のアプリプールを使用して）安全にプールを使用できます。

プロセスごとに1つのスレッドプールがあります。 スレッドプールのデフォルトサイズは、使用可能なプロセッサごとに250ワーカースレッドで、1000のI / O完了スレッドがあります。スレッドプール内のスレッド数は、SetMaxThreadsメソッドを使用して変更できます。各スレッドはデフォルトのスタックサイズを使用し、デフォルトの優先順位で実行されます。

私は先週職場で同様の質問をされました、そして私はあなたに同じ答えを与えます。リクエストごとにマルチスレッドWebアプリケーションを使用するのはなぜですか？Webサーバーは、多くの要求をタイムリーに（つまりマルチスレッドで）提供するために大幅に最適化された素晴らしいシステムです。Web上のほとんどすべてのページをリクエストするとどうなるか考えてみてください。

1. あるページに対してリクエストが行われた
2. HTMLが返されます
3. Htmlはクライアントに、さらにリクエスト（js、css、画像など）を行うように指示します。
4. 詳細情報が提供されます

リモートロギングの例を示しますが、それはロガーの懸念事項です。メッセージをタイムリーに受信するには、非同期プロセスを用意する必要があります。Samは、ロガー（log4net）がすでにこれをサポートしているはずだとさえ指摘しています。

Samは、CLRでスレッドプールを使用してもIISのスレッドプールで問題が発生しないという点でも正しいです。ただし、ここで問題になるのは、プロセスからスレッドを生成するのではなく、IISスレッドプールスレッドから新しいスレッドを生成することです。違いがあり、区別が重要です。

スレッドとプロセス

スレッドとプロセスはどちらも、アプリケーションを並列化する方法です。ただし、プロセスは独立した実行ユニットであり、独自の状態情報を含み、独自のアドレススペースを使用し、プロセス間通信メカニズム（通常はオペレーティングシステムによって管理される）を介してのみ相互に対話します。アプリケーションは通常、設計段階でプロセスに分割され、マスタープロセスは、重要なアプリケーション機能を論理的に分離することに意味がある場合、サブプロセスを明示的に生成します。言い換えれば、プロセスはアーキテクチャの構成要素です。

対照的に、スレッドは、アプリケーションのアーキテクチャに影響を与えないコーディング構造です。1つのプロセスに複数のスレッドが含まれる場合があります。プロセス内のすべてのスレッドは同じ状態と同じメモリ空間を共有し、同じ変数を共有するため、互いに直接通信できます。

ソース

参照されている記事（C＃feeds.com）に同意しません。新しいスレッドを作成するのは簡単ですが、危険です。単一コアで実行するアクティブスレッドの最適数は、実際には驚くほど低く、10未満です。マイナータスク用にスレッドが作成された場合、マシンがスレッドの切り替えに時間を浪費するのは簡単すぎます。スレッドは、管理が必要なリソースです。これを処理するためにWorkItem抽象化があります。

要求に使用できるスレッドの数を減らすことと、スレッドを効率的に処理するにはスレッドを作成しすぎることの間には、トレードオフがあります。これは非常に動的な状況ですが、スレッドの作成を先に進めるためにプロセッサに任せるのではなく、アクティブに管理する必要がある（この場合はスレッドプールによって）必要があると思います。

最後に、この記事ではThreadPoolを使用することの危険性についてかなり抜本的な説明をしていますが、実際にはそれらをバックアップするための具体的なものが必要です。

IISが同じThreadPoolを使用して着信要求を処理するかどうかは、明確な回答を得ることは難しく、バージョンが変わったようです。したがって、IISで多数のスレッドを使用できるように、ThreadPoolスレッドを過度に使用しないことをお勧めします。一方、小さなタスクごとに独自のスレッドを生成することは悪い考えのようです。おそらく、ロギングに何らかのロックがあるため、一度に1つのスレッドしか処理できず、残りは順番にスケジュールとスケジュール解除を繰り返すだけです（新しいスレッドの生成のオーバーヘッドは言うまでもありません）。基本的に、ThreadPoolが回避するように設計された正確な問題に遭遇します。

アプリがメッセージを渡すことができる単一のロギングスレッドを割り当てるのは、妥当な妥協案のようです。アプリの速度を落とさないように、メッセージの送信はできるだけ高速になるように注意する必要があります。

Parallel.ForまたはParallel.ForEachを使用して、スムーズに実行し、プールの枯渇を防ぐために割り当てるスレッドの上限を定義できます。

ただし、バックグラウンドで実行する場合は、ASP.Net Webアプリケーションで以下の純粋なTPLスタイルを使用する必要があります。

var ts = new CancellationTokenSource();
CancellationToken ct = ts.Token;

ParallelOptions po = new ParallelOptions();
            po.CancellationToken = ts.Token;
            po.MaxDegreeOfParallelism = 6; //limit here

 Task.Factory.StartNew(()=>
                {                        
                  Parallel.ForEach(collectionList, po, (collectionItem) =>
                  {
                     //Code Here PostLog(logEvent);
                  }
                });