Jettyで(ブロッキングIOを使用して)サーブレットとして実行されるRESTfulWebサービスを開発しています。最大スレッドの最適な設定を見つけるのは難しいようです。
セットアップの残りの部分のいくつかの簡単に測定可能な特性からスレッドの最大数を決定するための研究された公式はありますか?
Jettyで(ブロッキングIOを使用して)サーブレットとして実行されるRESTfulWebサービスを開発しています。最大スレッドの最適な設定を見つけるのは難しいようです。
セットアップの残りの部分のいくつかの簡単に測定可能な特性からスレッドの最大数を決定するための研究された公式はありますか?
非常に単純で原始的なもの:
max_number_of_threads = number_of_CPUs * C
Cはアプリケーションの他の要因に依存します:-)
次の質問を自問してください。
通常、私は C をかなり低く、例えば 2 ~ 10 に設定します。
いいえ、ありません。スレッドの数を制限して管理し、システムリソースを超えないようにします。通常、Javaの制限は約100〜200のライブスレッドです。
これを行う良い方法は、java.util.concurrentのエグゼキュータを使用することです。
この質問がされた時点で、Servlet 3.0 はリリースされていなかったことを理解しています。しかし、この質問では、Servlet 3.0 を使用して Servlet コンテナーで Async 処理を行う可能性を記録する必要があると考えました。これは、この質問に出くわした人を助けるかもしれません。言うまでもなく、サーブレット 3.0 には十分なリソースがあり、メインのサーブレット スレッドの負荷が軽減されていることがわかります。また、Servlet 3.0 API 自体を使用したくない場合に備えて、Jetty には対応する非同期機能があります。
ありがとう。簡単な公式はないので、これを読みました。:-(
(私のアプリは HTML5 バリデーターです。明らかに外部サーバーで待機していることもあります。ただし、それ自体またはガベージ コレクターを介して実際に CPU バインドされている場合を特定するのは困難です。)
答えは、処理すると予想される同時接続の最大数によって異なります。予想される接続と同じ数のスレッドを許可する必要があります。
andreasmk2 は、スレッド数について正しくありません。1000 スレッドのアプリを実行しましたが、システム リソースに問題はありませんでした。もちろん、システムの仕様によって異なります。Javaの制限ではなく、システムの制限に遭遇するでしょう。
私の問題は、同時接続数の合理的な期待値を形成する方法がわからないことです。おそらくある時点で、処理中の make 要求が多すぎるため、すべてを遅くするよりも、新しい接続を拒否する方がよいでしょう。
現実的なワークロードをシミュレートするのは難しいため、他の誰かによって既に研究されている式を探しています。
(明らかな上限は、最大ヒープ サイズをリクエストの処理に必要な最小メモリ量で割った値ですが、ガベージ コレクタのある環境ではそれを測定することさえ困難です。)