47

私はJMeterでいくつかの基本的なテストを書き始めましたが、測定値がApacheabの測定値と大きく異なることに驚いていました。

Nginxを実行しているInteli7サーバーとJMeterまたはabを実行しているi5テストマシンを接続するギガビットLANがあります。最初は、すぐに使用できるNginxホームページの応答率をテストしているだけです。

ab -c 1 -n 100 http://testserver.local/

与える

Document Path:          /
Document Length:        151 bytes

Concurrency Level:      1
Time taken for tests:   0.078 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      38400 bytes
HTML transferred:       15100 bytes
Requests per second:    1280.77 [#/sec] (mean)
Time per request:       0.781 [ms] (mean)
Time per request:       0.781 [ms] (mean, across all concurrent requests)
Transfer rate:          480.29 [Kbytes/sec] received

この結果は一貫して再現可能であり、+/-数パーセントです。


JMeterには、以下を含む1ユーザーの100ループスレッドグループがあります。

  • HTTPヘッダーマネージャーの設定Accept-Encoding：gzip
  • HTTPGet/サンプラー
  • 要約レポートリスナー

サンプルが100個しかないため、実行するたびに非常に一貫性のない結果が得られます。しかし、最も驚くべき事実は、スループットが1秒あたり40リクエスト（1280ではない）と報告されていることです。記録された最高のレートは1030でしたが、これは10,000サンプルに増やしたときにのみ達成されました。

JMeterはオーバーヘッドが高すぎて正確な測定ができないため、単純な負荷テストには不適切なツールであると私は考えていますか？

4

3 に答える 3

68

Jmeterは、各リクエストが実際にかかった時間を示します。ABは、全体的な平均を取得するために、いくつかの非常に基本的な計算を実行します。したがって、あなたの質問に対する直接の答えは、jmeterがそれを正しく理解し、abがすべての平均を与えることによって大まかな推測を行うということです。

ただし、確かに、2つのツールを並べて速度を評価すると、abがjmeterを実行しなくなることは明らかです。Jmeterはより多くのことを実行し、より多くのデータを記録し、より多くのロジックを処理するため、単一のリクエストを処理するのに時間がかかります。単純な事実は、Jmeterは完全な機能を備えた負荷テストツールですが、ABはそうではありません。

重要なのは、負荷テストツールの目的は、ブロックで最速の子供になることではなく、アプリが稼働したときにアプリが受ける可能性のある負荷の種類を現実的に表現できるようにすることです。この点で、jmeterは手に負えないので、実際には要件によって異なります。最小限のハードウェアを使用してできるだけ多くのリクエストを生成したい場合はabが良い選択ですが、トランザクションジャーニー、条件付きロジック、その他のあらゆる種類の便利なものを使用して代表的なテストを構築したい場合は、jmeterは行く方法。どちらもApacheプロジェクトですが、ABはApache Webサーバーをテストするように設計されていたと思いますが、JMeterはTomcatをテストするように設計されています。

さて、jmeterは、実行しているマシンの制限に達していたため、一貫性のない結果を生成していたと推測しています。GUIモードで実行していて、少なくとも1つのリスナーがアクティブになっていると思います。このように、ツールに多くのことを実行するように要求しています。高いレートのリクエストが必要な場合、Jmeterにはリーンモードと平均モードがあります。通常、大容量の場合のベストプラクティスは、リスナーが非常に少ないコマンドラインでテストを実行することです。apache jmeterサイトには、このテーマに関する多くの情報があります。

負荷テストを実際に行っている場合に考慮すべきもう1つのポイントは、この種のメリットを実際に得るには、まずサイトでサポートする必要のある負荷の種類を決定してから、設計する必要があるということです。これを表すテスト。これは、ペーシングとシミュレートされた待機時間を使用して実現されます。スレッドを停止して可能な限り高速に実行するように指示する際の問題は、ローカルの条件で可能な限り高速に反復することですが、常に中断を引き起こすものがあります。限定; どんなに軽量なツールでも、それでも何かをします。しかし、リクエストのペースを調整すると、この問題が解消され、かなり便利な追加ボーナスとして、実行間およびコードのビルド間で一貫性が保たれるため、サーバーの速度が向上または低下した場合でも（コードベースの変更により）テストでは引き続き同じレートのリクエストが作成されます。これはベンチマークに非常に役立ちます。

JMeterをさらに発展させたい場合は、Constant Throughput Timerを確認してから、複数のスレッドを使用して、表現する必要のあるトラフィックのレベルを構築してください。

于 2012-04-22T01:29:17.090 に答える
7

セットアップでは、JMeterはWebサーバーを飽和させるよりも速く飽和します。

非常に最適化されたCWebサーバーを優れたハードウェアで実行し、それをより少ないハードウェアで比較的重いJavaアプリでベンチマークします。最適化されたCマシンコードは、（おそらく）常にJavaバイトコードよりも高速です。JMeterはNginxに追いつくことができないため、ハードウェアの制限にぶつかると奇妙な結果が得られます。Javaは、ハードウェアリソースを管理するだけでなく、極端なリソース使用量で予測できない動作を作成する多くの優れた機能をバックグラウンドで実行します。一方、ApacheBenchは、サーバーを飽和させることができ、Webサーバーを飽和させた後に容量が過剰になるため、一貫した結果を生成できる十分なCプログラムです。

JMeterは、リクエストの処理に時間がかかる、より重い動的アプリケーションのベンチマークに最適です。それが提供するすべての追加データは、そのようなWebアプリに役立ちます。高度に最適化されたWebサーバーで静的ファイルサービング（Webサーバーが実行できるほぼ最速の処理）を処理する場合、それに追いつくのに十分な速度のツールが必要です。

于 2016-01-10T05:57:05.337 に答える
1

最初の回答ですでに述べたように、キーワード「要件」。JMeterは、Webページを提供するサーバーのテストに適しています。たとえば、一連のリクエストを送信し、シーケンスごとに異なるリクエストを生成し、HTML応答を解析し、HTMLから画像とスクリプトのコンテンツを読み込むことができます。ABはRESTAPIテストに適しています。サーバーが可能な限り高速に応答し、可能な限り多くのリクエストを処理する必要があり、後続の2つのリクエスト間に接続がない場合などです。したがって、ABは実際にJMeterと同じクライアントマシンの同じサーバー。

于 2017-01-03T14:25:17.593 に答える