JMeter集計レポートのスループットエラー分析

Jmeter Aggregate Report Throughput Error Analysis

はじめに：最近、同社はストレステストを実施するプロジェクトを実施しています。ストレステストの後、tpsが期待された目標を達成していないことがわかりました。最後に、手動でtpsを計算しました。偶然に問題が発見されました。 JMeterレポートのスループットエラーは大きかったです！

次の集計レポートは私が開始したデモであり、結果は次のとおりです。

古典的な理論モデルによれば、スループットTPSまたはQPSは、同時スレッドの数を平均応答時間で割ったものに等しくなければなりません。

tps = Thread / AVG（t）（同時スレッドの数を平均応答時間で割ったもの）

またはtps = COUNT（request）/ T（リクエストの総数をリクエストの合計時間で割ったもの）

上の図の要約結果を見てみましょう。平均応答時間は494ミリ秒、同時実行性は30、計算されたスループットは60.73 /秒、JMeterによって与えられたスループットは50.04、エラーの差は10です。

このような大きなエラーの理由は何ですか？ストレステストの実験を繰り返した後、デモではより定期的なマッチングを使用して応答の戻り値とさまざまなアサーションを検証していることがわかりました。それはJMeterの処理です。戻り値は多くの時間を消費し、計算スループットエラーを引き起こしますか？

それでは、実験を通してそれを検証しましょう。最初にスクリプトを作成し、シングルスレッドスクリプトを使用して、結果を10回確認するように依頼しました。

結果を見ると、平均応答時間は217ms、1回同時、計算結果は4.61 / s、JMeterの結果は4.6 / sであり、予想通りです。

次に、Groovyポストプロセッサを使用し、スレッドを500ミリ秒間スリープさせてから、同時にシングルスレッド化し、結果を10回要求しました。

結果を見ると、平均応答時間は219msであり、最初の平均応答時間である217msとほぼ同じです。計算結果は4.57 / sであり、JMeterによって与えられたスループット値は1.5 / sです。コントラストエラーは巨大です。

では、1.5 / sのスループットはどのように発生するのでしょうか？ 500msの待機を219msに追加します（500 * 9/10をここに追加する必要があります）。計算結果は1 /（219 + 500 * 9/10）= 1.49であり、これはJMeterによって与えられた1.5と一致します。基本的に結論JMeterがスループットを計算するとき、それはマシンの処理を考慮に入れます。

要求プロセス全体でのJMeterの平均応答時間が、通常の統計要求が送信されてから応答が受信されるまでの時間であるが、スループットが不足している場合は、マシンのスレッド全体の時間が基準として使用されます。スループット計算用。

定期的な抽出、パラメーターの検証、変数の割り当てなど、スレッド内で他のことを行うと、スループットが低下します。ローカルマシンの処理時間が長くなると、圧力テスト中のサーバーへの実際の圧力は、構成された圧力よりも小さくなります。マシンのパフォーマンスが高すぎる場合、または一部の場所で待機している場合、取得されたスループットは偽のデータと見なすことができます。対処しました。

エラーが大きいことがわかった場合は、誤ったデータを回避するために結果を修正する必要があります。