問題タブ [threadpool]

コードから iis からの 1 つの asp.net 要求を処理している間に、バックグラウンド タスクを処理するためにスレッド プールから子スレッドを作成したシナリオがあります。子スレッド タスク。しかし、私たちの疑問は、asp.net でリクエストを処理している間、スレッドがそのタスクを終了するまで workerprocess が wi​​at するのでしょうか?

セットアップは次のとおりです。FeedDotNetライブラリを使用するフィード リーダーである、比較的単純な Winforms アプリを作成しようとしています。私が持っている質問は、スレッドプールの使用についてです。FeedDotNet は同期 HttpWebRequest を作成しているため、GUI スレッドをブロックしています。そのため、ThreadPool スレッドに同期呼び出しを配置し​​、それが機能している間に、フォームで更新が必要なコントロールを呼び出すのが最善の方法のように思えました。いくつかの大まかなコード:

this= メイン フォーム インスタンス

updatesPending= メインフォームの volatile int

ProcessFeedResult= Feed オブジェクトに対していくつかの操作を行うメソッド。スレッドプール スレッドは結果を返すことができないため、これはメイン スレッドを介して結果を処理する許容可能な方法ですか?

私が最も心配しているのは、これがどのようにスケールするかです。一度に最大 250 件のリクエストを試しました。私が確認したスレッドの最大数は約 53 で、すべてのスレッドが完了すると 21 に戻りました。コードをいじってみた例外的な例の 1 つを思い出すと、120 まで上昇するのを見たことがありました。普通ですよね？また、Windows XP を使用しているため、接続数が非常に多いと、どこかにボトルネックがあると思います。私は正しいですか？

スレッド/接続の最大効率を確保するにはどうすればよいですか?

これらすべての質問があると、これがスレッドプールの使用に適しているかどうかも疑問に思いました。MSDN やその他の情報源は、「短期間の」タスクに使用する必要があると述べています。比較的高速な接続を使用していることを考えると、1 ～ 2 秒の「短命」で十分ですか? ユーザーが 56K のダイヤルアップを使用していて、1 つの要求に 5 ～ 12 秒以上かかる場合はどうなるでしょうか。その場合、スレッドプールも効率的なソリューションになるでしょうか?

特定のニーズに合わせて最適化されたカスタムThreadPoolを作成しました。ただし、プロセスに複数のAppDomainがある場合、CLR ThreadPoolはすべてのAppDomain間で共有できるため、この動作を再現できるようにしたいと思います。

これは、分散ThreadPoolを作成するためにMarshalByRefObjectとRemotingを使用して実行できますが、カスタムスレッドプールの主な目標はパフォーマンスであるため、不要なオーバーヘッドが追加されるのではないかと心配しています。

もう1つの理論的な解決策は、アンマネージオブジェクトを使用してAppDomainのメモリ境界をハックすることです。私が正しければ、AppDomainのメモリ境界は管理対象オブジェクトにのみ適用されるため、各AppDomainに1つの管理対象ラッパーがあり、すべて同じ非管理対象オブジェクトを指している可能性があります。

だから私の質問は：

1. 最小限のオーバーヘッドでリモート処理を使用してカスタムスレッドプールを作成する方法はありますか？
2. そうでない場合、AppDomain間でアンマネージオブジェクトを共有することは可能ですか？

現在、多数の製品の見積もりを実行するASP.NETアプリを拡張しています。

現在、既存の見積もりエンジンは基本的に大きなストアドプロシージャ（呼び出しごとに2〜3秒）であり、その後にプロシージャ呼び出しの後に実行される少量のビジネスロジックが続きます。

一連の見積もりをスピードアップするために、各製品への呼び出しをマルチスレッド化することを検討しています。

現在のアプローチは、各製品見積もり作業をThreadPoolスレッドにカプセル化することです。これはパフォーマンスがはるかに優れているように見えますが、少数のユーザーでうまく機能しているにもかかわらず、本番環境でうまく拡張できるかどうか少し心配しています。

現在、非同期ADO.NETメソッドを使用していないことに注意してください。

注：ThreadPoolを呼び出すコードには、リクエストをキューに入れるスロットルがあるため、一度にThreadPoolから構成可能な量のスレッドのみを使用できます。また、同じページで見積もり結果を待つ必要はありません。ユーザーが進行して更新を確認できるようにします（見積もり結果ページはAJAXを使用して結果を確認します）。

さらに注意：見積もりサービスは一方向の操作であるため、推奨される解決策はメッセージキューを使用することです。しかし、プロジェクトのタイムスケールでは、これを行う時間がありませんでした。

それまでの間、ADO.NETの非同期メソッドを使用するように実装を修正します（プロセスの長期的な側面がすべてここにあるため）。ThreadPoolスレッドを使用する必要がなくなります。

現在 3 つのタイマーを持つ Windows サービスを作成しました。最初のタイマーは 15 秒ごとに起動し、2 番目のタイマーは 1 分ごとに起動します。3番目のタイマーは毎日起きています。

問題は、これらが毎回新しいスレッドを生成し、一度スレッドプールが完全に使い果たされることです.3つのスレッドを生成するだけで、それ以上新しいスレッドを生成しないことはありますか.

私のコードは次のようになります。

ご覧のとおり、ある時点でスレッドプール内のすべてのスレッドを使い果たし、Windows サービスを突然停止する新しいスレッドを作成しています。現在、イベント ID 5000 の evet ログを停止してログしています。

.NET 4.0で見たことがあるかもしれませんが、彼らは新しい名前空間System.Threading.Tasksを追加しました。これは基本的にはタスクです。ThreadPoolを使用してから、数日間しか使用していません。

どちらがより効率的でリソース消費が少ないですか？（または全体的に良いですか？）

コードの一部があります：

私のテスト クライアント アプリケーションは、50 スレッドでそのサービスを呼び出します (サービスは PerCall です)。私が非常に気がかりなのは、Thread.Sleep(20000) を追加したときです。WCF は、プールとは異なるスレッドを使用して、毎秒 1 つのサービス インスタンスを作成します。

Thread.Sleep(20000) を削除すると、50 個のインスタンスがすぐにインスタンス化され、それを行うために約 2 ～ 4 個のスレッドが使用されます。実際、これは正常だと考えています。

Thread.Sleep がインスタンスの作成でおかしな遅延を引き起こす理由を誰か説明できますか?

処理対象アイテムと処理中アイテムの両方の破棄をサポートするバックグラウンド処理エンジンを構築しています。これは、いくつかの入力要素の重い処理を必要とする winforms アプリケーションで使用するためのものです。そのため、ワークロード アイテムをキューに入れることができるキュー エンジンを構築しています。それらが処理されると、結果が通知されます。

問題は、このキューにはほとんどの場合、最初から多くのアイテムが含まれているということです。すべてをスレッドプールにダンプするのではなく、最初の N 個のアイテムのみをスレッドプールに配置し、それらが存在する場合はバックフィルを続けます。処理されます。これを行う理由は、それらをスレッドプールにダンプすると処理され、破棄としてタグ付けされていても、キュー時間がかかるためです。

私が作成したバックフィルの実装を使用すると、アイテムが破棄された場合にキューからアイテムを削除し、いわば自分の順番になったときにのみキューに入れることができます。

問題は、この数 N (スレッド プール キューに配置して保持するアイテムの数) をどのように計算するかということです。

私が検討した問題：

• すべてのプロセッサが機能していることを確認するために、2 * プロセッサの数をキューに入れたいと思うかもしれません。これは典型的なアイテム数です。
• ただし、一部のアイテムの実際の処理が超高速である場合 (発生する可能性があります)、自分のクラスがより多くの作業をバックフィルする前に、スレッドプールのキューが使い果たされます。プロセッサ
• 各アイテムにかかる現在の時間に基づいて最適な数を計算するための自動調整ルーチンを作成する必要があるため、それらがすべて超高速である場合、数ははるかに高くなり、処理に少し時間がかかる場合はそのままになります。低い？

どう思いますか？

New : わかりました。回答の 1 つにより、もう少し説明します。キューに入れられるすべてのアイテムは、一意のものによってキーが付けられます。既存のアイテムと同じキーを持つ別のアイテムをキューにダンプすると、その古いアイテムは「破棄」と見なされ、削除する必要があります。アイテムが処理中の場合、ワークロード アイテムのプロパティが true に設定されます。これは、処理メソッドが呼び出す「IsDicarded」プロパティです。破棄されたアイテムを検出した場合は、結果を返さずに早期に終了する必要があります。

おそらく、もう少し実験して、すべてをスレッドプールにダンプする必要があります。

新しい質問: キューに入れることができるアイテムの数に制限はありますか? そうでない場合、これは私のクラスを簡単に簡素化します。

注: 「処理が長い」とは、1 ～ 10 秒程度のことです。スレッドプールはこれに最適ですか? 「処理は速くあるべきだ」というメモを Web のいたるところで見かけますが、「速い」とは何かについては言及されていません。ここはミリ秒単位で速いですか？

スレッドプールから4つのワーカースレッドを持つアプリケーションがあります。0.5秒ごとに起きていました。msdnに記述されているように、スレッドプールは0.5秒ごとに監視して、アイドル状態のスレッドを作成します。最小スレッド数を4に設定すると、問題が解決しました。これ以上のバックグラウンドアクティビティはありません。私の質問は-同じスレッド数のスレッドが4つある別のアプリケーションがありますが、ここで最小スレッドを4に設定しても効果はありませんが、最小スレッドを5に設定すると、バックグラウンド監視が停止します。スレッドプールからのスレッド数が同じである2つのアプリケーション（4つのスレッド）の違いは何でしょうか.1つは最小スレッドを4に設定し、もう1つは最小スレッドを5に設定するだけです。

私は次の2つの方法を使用しています。DoMyWork1 と呼ばれるメソッドは、3 つのスレッドで 3 つのメソッドを実行するのに 6 秒かかるなど、適切にスケーリングします。一方、DoMyJob メソッドはまったくスケーリングしません。1 つのスレッドに 4 秒かかる場合、3 つのスレッドを実行するには 13 秒かかります。私は何を間違っていますか？ファイルの読み取りおよび/または書き込みには、スレッド プール以外の特別なスレッド処理が必要ですか?

私の呼び出しコード