問題をデバッグする方法について少し助けが必要です。私の現在の jMeter シナリオは、ループ カウントを 1 に保っている限り問題なく動作しているように見えます。ループを追加すると、パフォーマンスが大幅に低下し始めます。
225 スレッド、110 秒のランプアップ、ループ カウント 1 のスレッド グループがあります。合計応答時間は約 . 8～9秒。確認のためにこれを数回実行すると、各実行で同様の応答時間が示されます。ここで、同じテストを行いました。ループ回数を 3 に変更しただけで、他のすべてのパラメーターは変更しませんでした。パフォーマンスは低下し、合計応答時間は約 . 30～40代。
私は、3x1 ループの実行は、多かれ少なかれ、1x3 ループの実行と同等であるという印象を受けました。それは問題ではないようです。その理由を説明できる人はいますか？または、これが同等である場合、パフォーマンスを低下させる原因をどこで探すべきか考えていますか?
あなたが言っているのは、スループットを上げると、応答時間が低下するということです (1 秒あたりの要求のように)。
110 秒のランプアップで 1 つのリクエストを行う 225 のスレッドに基づくと、スループットは毎秒 2 リクエストの領域になります。ループ カウントを 3 に増やすと、1 秒あたりの要求数が約 3 ～ 6 倍になります (タイマーがない場合)。もちろん、応答時間が増加している場合を除いて、問題であるこのレベルのスループットには到達しません。
このリクエストがすでに 8 ～ 9 秒かかっていることを考えると、これは特に高速ではありません。舞台裏で重い思考が行われており、どこかでボトルネックにぶつかっただけであると推測できます...
使用するスレッドを減らし、ランプアップを長くしてから、応答時間とスループット レートを監視してください。ある時点で、負荷が増加するにつれて、応答時間が低下し始めることがわかります。この時点で、袖をまくり上げて、AUT で何が起こっているかを確認する必要があります。
ノート。3 x 1 ループは 1 x 3 ループと同じではありません。反復間の遅延により、複数の反復を持つ 1 つのスレッドのスループットと、遅延ではなくランプアップによってスループットが決定される 1 つの反復を持つ複数のスレッドのスループットが異なります。とはいえ、これは質問で説明したものではありません-スレッドの数は一貫していると述べています。
Oliver からの回答に加えて、Active Threads Over Time Listenerのようなカスタム リスナーを使用してみてください - 負荷シナリオを監視します。
このリスナーを使用して、上記の両方のシナリオを再試行することもできます。確かに、グラフの違いがわかります。