18

Java で FixedThreadPool Executor オブジェクトを作成する場合、Executor が同時に実行できるスレッドの数を示す引数を渡す必要があります。私は、電話番号の大規模なコレクションを処理することを担当するサービス クラスを構築しています。電話番号ごとに、Web サービスを実行する必要があり (これがボトルネックです)、応答をハッシュマップに保存する必要があります。

このボトルネックによるサービスのパフォーマンスへの悪影響を軽減するために、未処理の要素を取得して処理する Worker クラスを作成することにしました。Worker クラスは Runnable インターフェイスを実装し、Executor を使用して Workers を実行します。

同時に実行できる Worker の数は、Executor FixedThreadPool のサイズによって異なります。ThreadPool の安全なサイズはどれくらいですか? 大きな数を引数として FixedTheradPool を作成するとどうなりますか?

4

9 に答える 9

8

考えられる何かが見ている

Runtime.getRuntime().availableProcessors()

これにより、システムにとって意味のあるスレッドの数についてある程度の方向性が示されます。

于 2010-07-12T02:27:38.593 に答える
6

各ワーカー スレッドが Web サービスの呼び出しを行う必要がある場合、プール内のスレッドの数は、Web サービスが処理できる同時要求の数によって大きく左右されます。それ以上のスレッドは、Web サービスを圧倒するだけです。

于 2009-06-22T18:30:54.017 に答える
2

Web サービスへの開発アクセス権がある場合は、バッチ関数を作成して、1 回の通話で複数の電話番号を確認することを検討してください。

新しい .NET には、独自のパフォーマンス プロファイルに基づいて拡大および縮小できる ThreadPool があります。残念ながら、Java のバージョンは Fixed であるか、または入ってくる作業に基づいて制限まで成長します。

かつて同様の懸念がありました。私たちの解決策は、顧客がプール サイズを調整し、パフォーマンスを好きなように調整できるようにすることでした。

I/O オペレーション プールのサイジングでは、ネットワークとデータのプロパティが考慮される場合があります。ネットワーク帯域幅、メッセージ サイズ、Web サービスの処理時間とスタイル、ローカル コアの数などです。

于 2009-06-22T18:35:01.327 に答える
2

各計算が Web サービスの呼び出しに相当する場合、そのサービスにかける負荷と、そのサービスが許容する、またはサービスの所有者によって許可される同時接続の数を考慮する必要があります。ほとんどの公的にアクセス可能なサービスは、一度に 1 人のユーザーからのそのような接続を 1 つだけ想定します。可能であれば、サービスの所有者に連絡して、使用ポリシーを確認してください。このような接続の数によって、使用できるスレッドの数が決まります。

于 2009-06-22T18:35:05.977 に答える
2

最適なスレッド数はコア数 * 25 であるとどこかで読んだことがあります。.NET はこれを ThreadPool のデフォルトとして使用しているようです。ただし、多数の Web サービス呼び出しがある場合は、単一のスレッドを使用して、Web サービス呼び出しのリストで応答を確認することをお勧めします。応答が到着したら、エントリを処理してリストから削除します。

于 2009-06-22T18:30:19.590 に答える
1

Webサービスは無限にスケーラブルであり、リクエストでスパムを送信していることを誰も気にしないと仮定しましょう。また、ローカル処理時間が5ミリ秒であるのに対し、Webサービスの応答が1秒の範囲にあると仮定します。

処理コアと同じ量のビジースレッドがある場合、スループットは最大になります。

これらの仮定の下では、任意のサイズのスレッドプールに対してマルチコアプロセッサのスループットを最大化することはできません。1秒あたりのトランザクション数を最大にするには、接続モデルごとにスレッドを切断する必要があります。前述のノンブロッキングI/O（NIO）、または非同期完了トークンパターンのJava実装（WindowsではIO完了）を探します。

作成されたすべてのスレッド用に予約されているスタックメモリは、実際には予約されたアドレススペースであり、実際に割り当てられたメモリやコミットされたメモリではないことに注意してください。スタックが大きくなると、例外がスローされ、スタックメモリがオンデマンドでコミットされます。その結果、32ビットメモリマネージャにのみ実際に関連することになります。64ビットメモリの場合、物理メモリでそのスペースのごく一部をバックアップするだけでも、巨大なアドレススペースがあります。少なくとも、これは私がWindowsが機能することを理解する方法であり、Unixの世界についてはよくわかりません。

于 2009-06-22T20:38:46.877 に答える
0

作成する各スレッドも、そのスタック サイズのメモリを要求することを忘れないでください。そのため、スレッドのプールを作成すると、プロセスのメモリ フットプリントに影響を与えます (一部のプールは、実際に必要になるまでスレッドを作成しないため、起動時にメモリの増加は見られないことに注意してください)。

このスタック サイズは-Xss(などと同様-Xmx) を介して構成できます。デフォルトはスレッドあたり 512Kb だと思います。現時点では、それを確認するための信頼できるものを見つけることができません。

于 2009-06-22T18:40:01.273 に答える
0

並列配列操作などの大量の計算を行っている場合、経験則では、プロセッサの数に対してスレッドの数を設定します。

于 2009-06-22T19:16:21.083 に答える
0

制限要因はクライアントCPUではなく、Webサービスサーバー+ネットワークのボトルネックになるため、スレッドではなくNIOを使用したほうがよいのではないかと思います。

それ以外の場合は、Web サービスがサポートできる同時接続数を超えないようにしてください。

于 2009-06-22T19:05:54.630 に答える