JMeterとApache abのどちらが正しい測定値ですか？
私はJMeterでいくつかの基本的なテストを書き始めましたが、測定値がApache abの測定値と大きく異なることに驚きました。
Nginxを実行するIntel i7サーバーと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
- hTTP Get /サンプラー
- 要約レポートリスナー
100サンプルしかないため、実行するたびに非常に一貫性のない結果が得られます。しかし、最も驚くべき事実は、スループットが毎秒40リクエスト（1280ではない）と報告されていることです。記録された最高速度は1030でしたが、これは私が10,000サンプルに増やしたときにのみ達成されました。
オーバーヘッドが高すぎて正確な測定ができないため、JMeterは単純な負荷テストに適したツールではないと私は思いますか？
Jmeterは、各リクエスト実際ににかかった時間を示します。 ABは非常に基本的な計算を行って全体の平均を取得します。したがって、あなたの質問への直接の答えは、jmeterはそれを正しく理解し、abはすべての平均値を与えることによって大まかな推測をするということです。
しかし、2つのツールを並べて速度を評価すると、abがjmeterを実行するのは明らかです。 Jmeterは、より多くのことを実行し、より多くのデータを記録し、より多くのロジックを処理するため、単一の要求の処理に時間がかかります。簡単な事実は、Jmeterはフル機能の負荷テストツールですが、ABはそうではありません。
問題は、負荷テストツールの目的は、ブロックで最速の子供になることではなく、現実的なものを構築できるようにすることですアプリの公開時に発生する可能性のある負荷の表現。この点で、jmeterは勝者となるため、実際には要件によって異なります。最小限のハードウェアを使用してできるだけ多くのリクエストを生成したい場合は、abがいい選択ですが、トランザクションジャーニー、条件付きロジック、その他のあらゆる種類の有用なものを使用して、代表的なテストを構築したい場合、jmeterは行く方法。このように考えてください。どちらもApacheプロジェクトですが、ABはApache Webサーバーをテストするように設計されていましたが、JMeterはTomcatをテストするように設計されていました。
ここで、jmeterが実行されているマシンの制限に達していたため、jmeterが一貫性のない結果を生成していたと思います。私はあなたがGUIモードで実行していて、少なくとも1つのリスナーがアクティブであったと思います。このように、ツールに多くのことを求めています。高いリクエスト率が必要な場合、Jmeterには無駄のない平均モードがあります。通常、大量の場合のベストプラクティスは、非常に少数のリスナーを使用してコマンドラインでテストを実行することです。 Apache jmeterサイトには、この主題に関する多くの情報があります。
負荷テストを実際に行っている場合に考慮する必要があるもう1つのポイントは、この種のことから本当にメリットを得るには、サイトでサポートする必要のある負荷の種類を最初に決定し、それから設計する必要があるということです。これを表すテスト。これは、ペーシングとシミュレートされた待機時間を使用して実現されます。スレッドを削除してできるだけ早く実行するように指示することの問題は、ローカル条件が許す限り高速で反復することですが、は常にありますabが制限されていても、休憩を入れるものである。ツールがどれほど軽量であっても、それでも何かです。しかし、リクエストのペースを調整すると、この問題がなくなり、かなり便利な追加ボーナスとして、実行間およびコードのビルド間で一貫性が保たれるため、サーバーが高速化または低速化しても（コードベースの変更により）テストでは、同じ比率のリクエストが実行されます。これは、ベンチマークに非常に役立ちます。
JMeterをさらに活用したい場合は、定数スループットタイマーを確認し、複数のスレッドを使用して、表す必要のあるトラフィックのレベルを構築します。
セットアップでは、JMeterはWebサーバーを飽和させるよりも速く飽和します。
優れたハードウェアで非常に最適化されたC Webサーバーを実行しており、比較的ハードウェアが比較的重いJavaアプリでそれをベンチマークしています。最適化されたCマシンコードは（おそらく）常にJavaバイトコードより高速です。 JMeterはNginxに追いつくことができないため、ハードウェアの制限に達したため、奇妙な結果が得られます。 Javaは、ハードウェアリソースを管理するバックグラウンドで多くの優れた機能を実行しますが、極端なリソース使用時に予測できない動作を引き起こします。一方、ApacheBenchは、サーバーを飽和させ、Webサーバーを飽和させた後に容量が過剰になるため、一貫性のある結果を生成できる十分に軽いCプログラムです。
JMeterは、リクエストの処理に時間がかかる重い動的アプリケーションのベンチマークに最適です。それが提供するすべての追加データは、そのようなWebアプリに役立ちます。高度に最適化されたWebサーバーで静的ファイルサービス（Webサーバーで実行できる最高速の処理）を処理する場合は、十分に高速なツールが必要です。
最初の回答で既に述べたように、キーワード「要件」。 JMeterは、Webページを提供するサーバーのテストに適しています。たとえば、一連のリクエストを送信し、シーケンスごとに異なるリクエストを生成し、HTMLレスポンスを解析して、画像とスクリプトのコンテンツをHTMLからロードできます。 REST APIテストでは、ABの方が適しています。サーバーができるだけ速く応答し、できるだけ多くのリクエストを処理する必要がある場合、2つの後続のリクエストの間に接続がないなどです。したがって、 ABは、同じクライアントマシンから同じサーバーに対してJMeterよりも多くのリクエストを生成できます。