サービスの 1 つに対する要求を処理する webapp があります。Tomcat 7 サーバーで実行しています。以下で説明するように、作成できる最も基本的なサーブレットで同様の結果が得られるため、これ以上の詳細は必要ありません。
サービスへのリクエストを 1 分間実行するさまざまな数の同時スレッドを使用して、jmeter で負荷テストを実行します。結果を使用して、平均応答時間と同時スレッド、および 1 秒あたりのリクエスト数と同時スレッドの数を示すグラフを生成します。
私たちのテストでは、約 10 の同時スレッドで、アプリケーションによって管理されるスループットに限界があることがわかりました。そのスレッド数から開始すると、平均応答時間が増加し、1 秒あたりの要求数が安定します。
すべてのアプリケーション ロジックを削除して静的応答を返すなど、アプリケーションに対するいくつかの変更をテストしました。また、何もしない基本的なサーブレットに対して同じテストを実行すると、同様の結果が得られました。平均応答時間とスループットの値は大幅に改善されましたが、テストでは約 10 の同時スレッドで限界に達しました。
また、テスト ツールの問題を破棄するために、Apache Benchmark で同様のテストを実行しました。
テストは、2 つのサーバー プールで実行されました。ローカル コンピューターで実行すると、同様の結果が得られましたが、約 5 つの同時スレッドでスループットの制限に達しました。
こちらがスループットチャートです。各行の値は重要ではないことに注意してください (たとえば、db アクセスが削除されているものや、ほとんどのアプリケーション ロジックで時間がかからないものもあります)。
私たちが理解したいのは、スループットの限界がどこから来ているのか、それを改善するために何ができるのかということです。
ありがとう、ホルヘ
PS: 単なるリンクではなく画像を追加したいのですが、十分な評判がないようです :(