ThreadPool.QueueUserWorkItemはASP.Netを使用します

Question

"ThreadPool.QueueUserWorkItem"を使用して巨大なpdfレポートを作成するためのAsp.Netで、私の要件は非同期的に作成する必要があり、応答を待っていません。私は、コードの下にそれを通じ達成する計画

protected void Button1_Click(object sender, EventArgs e) 
{ 
    ThreadPool.QueueUserWorkItem(report => CreateReport()); 
} 

public void CreateReport() 
{ 
    //This method will take 30 seconds to finish it work 
} 

私の質問は、ThreadPool.QueueUserWorkItemはAsp.Netワーカープロセスまたは一部のシステムスレッドから新しいスレッドを作成しますです。これは良いアプローチですか？100人の同時ユーザーがWebページにアクセスしている可能性があります。

Answer 1

ThreadPoolは、プロセスのThreadPoolを使用して、多数のワーカースレッドを自動的に管理します。これらのスレッドにはタスクが割り当てられ、スレッドは完了まで実行された後、ThreadPoolに戻されて再利用されます。

これはASP.NETでホストされているため、ThreadPoolはASP.NETプロセスに属します。

ThreadPoolは、このタイプの作業の非常に良い候補です。専用のスレッドをスピンアップする代わりに、比較的高価であるためです。しかし、あなたにもThreadPoolのの、次の制限を考慮する必要があります。

• ThreadPoolのは、.NETの他の側面で使用され、スレッドの数が限られています。それを多用すると、他の人が完了するのを待ってタスクがブロックされる可能性があります。これは特にスケーラビリティの点で懸念事項ですが、ボトルネックとなる理由がない限り、ThreadPoolの使用を断ってはいけません。

• ThreadPoolタスクは、再利用のために返されるように慎重に管理する必要があります。バックグラウンドスレッドからの未処理例外またはリターンは、そのスレッドを本質的に「リーク」させ、スレッドが再利用されないようにします。これらのシナリオでは、ThreadPoolはスレッドを効果的に失い、プロセスの深刻な減速または停止を引き起こす可能性があります。

• ThreadPoolに割り当てるタスクは短命でなければなりません。処理が集中する場合は、専用のスレッドを提供することをお勧めします。

すべてのこれらのトピックは、ThreadPoolのは、小さなタスクのために意図されたシンプルなコンセプトに関係する、とのためには、再利用されることにより、かかるコードにコスト削減を提供するスレッドです。あなたのシナリオは、ThreadPoolを使用する合理的なケースのように聞こえますが、その周りを慎重にコーディングし、現実的なロードテストを実行して最良のアプローチであるかどうかを確認する必要があります。

Answer 2

スレッドプールは、必要に応じてアクティブなスレッドの数を管理します。スレッドがタスクで完了すると、次のキューに入れられたタスクでスレッドが続行されます。スレッドプールの使用は、通常、バックグラウンド処理を処理するのに適しています。

ASP.NETアプリケーションで実行する場合の注意すべき点がいくつがあります

• ASP.NETアプリケーションは、様々な理由のために再利用することができます。これが起こると、すべての待ち行列に入れられた作業項目が失われます。
• 操作が完了したことをクライアントのWebブラウザに簡単に返信する方法はありません。

場合によっては、クライアントWebページのAJAXコードで呼び出されるREST/JSONバインディングを持つWCFサービスを使用する方がよいでしょう。これにより、プロセスと結果をユーザーに報告することができます。

Answer 3

Anders Abelが既に説明したことに加えて、私は完全に同意していますが、ASP.NETもリクエストに応答するためにスレッドプールを使用することを考慮する必要があります。スレッドプールスレッドでは、ASP.NETが他の要求を満たすために使用できるリソースから技術的に盗み出しています。

私にそれを最もうまく設計する方法を聞かれたら、MSMQトランスポートを介した片方向メッセージングを使用してWCFサービスに作業をディスパッチすると言います。メッセージが処理待ちのキューに置かれるだけであるため、WCF側での要求の処理と処理の復元性が向上し、より緊密に制御できます。だからあなたのサーバが一度に10のPDFを作成できるのであれば、WCFサービスのmaxConcurrentCallsを10に設定するだけで、最大10個のメッセージを一度にキューから取り出すことになります。また、サービスがシャットダウンされると、起動時に処理が再開されます。