HTTP サーブレット コンテナの最大スレッド数を選択するにはどうすればよいですか?

Question

Jetty でサーブレット (ブロッキング IO を使用) として実行される RESTful Web サービスを開発しています。最大スレッドの最適な設定を見つけるのは難しいようです。

セットアップの残りの部分の簡単に測定できる特性からスレッドの最大数を決定するための研究された公式はありますか?

Answer 1

非常にシンプルで原始的なもの:

最大スレッド数 = CPU 数 * C

ここで、C はアプリケーションの他の要素に依存します:-)

次の質問を自分自身に問いかけてください。

• アプリケーションは CPU を集中的に使用しますか (C が低い)、それとも 3 番目のシステムの待機にほとんどの時間を費やしますか (C が高い)?
• より速い応答時間が必要ですか (C が低い)、または各リクエストに時間がかかる場合でも複数のユーザーに一度にサービスを提供できる必要がありますか (C が高い)。

通常、私は C をかなり低く設定します。2～10。

Answer 2

いいえ、ありません。システム リソースを超過しないように、スレッド数を制限して制御します。Java の制限は通常約 100 ～ 200 のライブ スレッドです。

これを行う良い方法は、Executor を使用することです。 java.util.concurrent.

Answer 3

この質問が行われた時点では、Servlet 3.0 はリリースされていなかったと理解しています。しかし、この質問では、Servlet 3.0 を使用して Servlet コンテナ内で非同期処理を実行できる可能性について記録する必要があると考えました。これは、この質問に遭遇した人に役立つかもしれません。言うまでもなく、サーブレット 3.0 には十分なリソースがあり、メインのサーブレット スレッドの負荷が軽減されたことがわかります。また、Servlet 3.0 API 自体を使用したくない場合に備えて、Jetty には非同期の対応物があります。

Answer 4

答えは、処理すると予想される同時接続の最大数によって異なります。期待する接続数と同じだけのスレッドを許可する必要があります。

andreasmk2 のスレッド数が間違っています。1000 スレッドでアプリを実行しましたが、システム リソースに問題はありませんでした。もちろん、それはシステムの詳細によって異なります。遭遇するでしょう システム 制限ではなく、 ジャワ 制限。

Answer 5

私の問題は、同時接続数について適切な予測を立てる方法がわからないことです。おそらく、 いくつかの つまり、処理中の make リクエストが多すぎてすべてが遅くなるよりも、新しい接続を拒否する方が良いということです。

現実的なワークロードをシミュレートするのは難しいため、他の人がすでに研究した式を探しています。

(明らかな上限は、最大ヒープ サイズをリクエストの処理に必要な最小メモリ量で割ったものですが、ガベージ コレクターのある環境ではそれさえも測定するのが困難です。)

Answer 6

ありがとう。簡単な方程式はないので読んでみました。:-(

(私のアプリは HTML5 バリデーターです。明らかに外部サーバーで待機している場合もあります。ただし、CPU バウンドが実際に単独で発生しているのか、ガベージ コレクターを通じて発生しているのかを特定するのは困難です)。