多数のスレッド1を作成し、多数のリクエストを受け入れても、サーバーがリクエストを処理できるとは限りません
N 個のスレッドと M 個の物理プロセッサ/コアのみがある場合、各スレッドは 1 個のプロセッサを取得し、 の場合M >= N
は平均M / N
プロセッサを取得しM < N
ます。N 個のリクエストがそれぞれ 1 つのスレッドで実行されており、各リクエストにR
数秒の CPU 時間がかかるとします。T
1 つの要求を実行するのにかかった平均経過時間はT = Min(R, R * N / M) seconds
です。N
(アクティブなスレッドとアクティブなリクエストの数)を増やすT
と、個々のリクエストの平均経過時間が比例して増加することは明らかです。
それに加えて、スレッドが多数ある場合、それらはすべてメモリを使用し、共有データ構造またはデータベースへのアクセスをめぐって競合します。この余分なリソースの使用と競合のすべてが、システム全体のオーバーヘッドをさまざまな方法で増加させています。
したがって、私が推測しているのは、それぞれがリクエストを同時に処理しようとしているその数のスレッドで、時間T
がクライアントまたはサーバー側のリクエストのタイムアウトに近づき始めているということです。(また、スケジューラなどの気まぐれは、特定のリクエストの実際の時間が平均よりも短いか、平均よりもかなり長い可能性があることを意味することに注意してください。) リクエストがタイムアウトになると、取得するリクエストのスループットが低下します。これは、タイムアウトになった要求ごとに実行される作業が (通常) 無駄になるためです。
リクエストが遅い外部サービスとの通信を必要としない限り、スレッド数を 200 以下に減らすことをお勧めします... Tomcat のデフォルト2。これにより、システムのスループットが向上することを期待しています。その期間に開始された 1000 件のリクエストをすべて処理できるとは限りませんが、正常に処理されるリクエストの数が増えると予測しています。
1 - 実際、スレッド数を 1000 に増やしても、1000 のリクエストを受け入れることができるわけではありません。RUNNABLE 状態のスレッドが何百もある場合、Tomcat のリスナー スレッド ( を呼び出すスレッドServerSocket.accept()
) が CPU 不足になり、リクエストの到着率に追いつけなくなる可能性があります。
2 - システムのパフォーマンス チューニングを行う必要がありますが、それを減らしてさらに改善されたとしても、私は驚かないでしょう。それは、ハードウェア、アプリケーション、および (私が予想する) バックエンド データベースに依存します。