web-dev-qa-db-ja.com

JMeterを使用したテスト：1秒あたりNリクエストを実行する方法

システムが1秒あたりN個のリクエストを実行できるかどうかをテストする必要があります。技術的には、1つのAPIへの2つのリクエスト、別のAPIへの2つのリクエスト、3つ目のAPIへの6つのリクエストです。しかし、それらが同時に起こるべき重要なこと-1秒あたり10リクエスト。したがって、JMeterで3つのスレッドグループを作成しました。最初にスレッド1の数、ランプアップ時間0を定義します。2番目のスレッドグループは同じで、3番目のスレッドグループはスレッド数6とランプアップ時間0を定義します。それは実際にそれらを実行することを保証しませんper secondどうやってそれをエミュレートしますか？そして、結果をどのように見ることができますか？それが実行できたかどうか？

ありがとう！

jmeterload-testingperformance-testingstress-testing
49
alexeypro

他のネットワークテストと同様に、特に遅延には常に問題があります-could正確に1秒あたり6回送信しても、それらは順番に送信されます（パケットの送信方法です）その秒ですべてがヒットするわけではなく、さらに処理時間がかかる場合があります。

一般に、パフォーマンスメトリックが1秒あたりxに固有の場合、一定期間にわたって測定されます。 APIにはバッファがある場合もあります。したがって、技術的には1秒間に6を送信できますが、20のバッファで1秒間に5を処理できます。つまり、120を送信したので、20秒間のトラフィックで問題ありません。処理に120/5 = 24秒かかります。しかし、それ以上はバッファをオーバーフローさせます。したがって、テストするために1秒に正確に6を送信するだけでは不十分です。

スレッドグループでは、スレッド（ユーザー）の数を6に設定するのが適切です。その後、永久にループを実行し（チェックするか、whileループに入れます）、集計レポートや結果ツリーなどのリスナーを追加します。適切なものが送信され、応答されていることを確認するために使用できる結果（応答を検証すると仮定します）および集約レポートでは、1時間あたりの各アクティビティの数を確認できます（明らかに3600を秒で乗算しますが、この不正確さのため、適切な時間実行するのが最善です。

初期負荷テストを実行できるようになりました。より正確なテストとして、長時間実行したままにして（ソークテスト）、バッファオーバーフロー、メモリリーク、またはその他の予期しないイベントなど、他の問題が表面化するかどうかを確認できます。

33
Mark Mayo

ConstantThroughputTimerを使用できます。

以下のJMeterヘルプファイルからの引用：

18.6.4一定スループットタイマーこのタイマーは、合計スループット（1分あたりのサンプル数）を可能な限り一定に保つために計算される可変休止を導入します。もちろん、サーバーが処理できない場合、または他のタイマーや時間のかかるテスト要素がそれを妨げる場合、スループットは低くなります。 N.B.タイマーは一定スループットタイマーと呼ばれますが、スループット値は一定である必要はありません。変数または関数呼び出しの観点から定義でき、テスト中に値を変更できます。

たとえば、1秒あたり40のリクエストを生成するために使用しました：

 <ConstantThroughputTimer guiclass="TestBeanGUI" testclass="ConstantThroughputTimer" testname="Constant Throughput Timer" enabled="true">
      <stringProp name="calcMode">all active threads in current thread group</stringProp>
      <doubleProp>
        <name>throughput</name>
        <value>2400.0</value>
        <savedValue>0.0</savedValue>
      </doubleProp>
    </ConstantThroughputTimer>

それが要約です：

Created the tree successfully using performance/search-performance.jmx
Starting the test @ Tue Mar 15 16:28:39 CET 2011 (1300202919244)
Waiting for possible shutdown message on port 4445
Generate Summary Results +  3247 in  80,3s =   40,4/s Avg:    18 Min:     0 Max:  1328 Err:   108 (3,33%)
Generate Summary Results +  7199 in 180,0s =   40,0/s Avg:    15 Min:     1 Max:  2071 Err:   378 (5,25%)
Generate Summary Results = 10446 in 260,3s =   40,1/s Avg:    16 Min:     0 Max:  2071 Err:   486 (4,65%)
Generate Summary Results +  7200 in 180,0s =   40,0/s Avg:    14 Min:     0 Max:   152 Err:   399 (5,54%)
Generate Summary Results = 17646 in 440,4s =   40,1/s Avg:    15 Min:     0 Max:  2071 Err:   885 (5,02%)
Generate Summary Results +  7199 in 180,0s =   40,0/s Avg:    14 Min:     0 Max:  1797 Err:   436 (6,06%)
Generate Summary Results = 24845 in 620,4s =   40,0/s Avg:    15 Min:     0 Max:  2071 Err:  1321 (5,32%)

しかし、ネットワーク内でこのテストを実行します。

65
lb_lb

スループットシェーピングタイマー を使用します

18
Andrey Pokhilko

私は同様の問題を抱えていましたが、ここに私が見つけた2つの解決策があります：

ソリューション1：
一定のスループットタイマーを使用して、ステッピングスレッドグループを使用できます（設定された期間でスレッド数増加ステージを設定できます）。スループットタイマーを使用すると、スレッドが毎分送信できるサンプル数を設定できます（たとえば、1に設定すると、スレッドは毎分1つのリクエストのみを送信します）。また、スループットタイマーをスレッドグループ内のすべてのスレッドに適用したり、スレッドごとに独自の設定を持つタイマーを設定したりできます。スループットタイマーの詳細については、こちらをご覧ください。 https://www.blazemeter.com/blog/how-use-jmeters-throughput-constant-timer

解決策2：
「スレッドグループの設定」を使用します。スレッド数を計算し、希望する1秒あたりのスレッド数を取得する時間を増やすことができます。

1
Yury Ustsinchyk

Schedule Feedback Function を使用でき、同時実行スレッドグループも必要です。

0
raman rayat