先にJMeterのインストール方法などを投稿したがそもそもの話でJMeterって何?というところをまとめる
Apache JMeterの概要
- Javaで作られたオープンソースの負荷テストツール
- 様々なプロトコルに対応
- HTTP, REST, FTP, JDBC...
- GUIやプロキシツールでの操作記録を利用し複雑なシナリオの作成も可能
- リクエストごとに動的にパラメータを変更することも可能
- サーバモードによる分散テストも可能
- 結果の表示方法が豊富でテストレポートの作成もサポート
同種のツール
ab
- Apache HTTP serverに付属のシンプルなCLIベンチマーキングツール
- Apache HTTP server benchmarking tool ⇒ ab
- 単一のURLに対して簡単に負荷をかけることが可能
ab - Apache HTTP server benchmarking tool (公式)
実行例
ab -n 20 -c 4 http://localhost:8080/examples/jsp/
オプション例
オプション | 意味 |
---|---|
-n 数 | 全体のリクエスト数 |
-c 数 | 多重度 |
出力結果例
This is ApacheBench, Version 2.3 <$Revision: 1843412 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking localhost (be patient).....done
Server Software:
Server Hostname: localhost
Server Port: 8080
Document Path: /examples/jsp/
Document Length: 14697 bytes
Concurrency Level: 4
Time taken for tests: 0.007 seconds
Complete requests: 20
Failed requests: 0
Total transferred: 298340 bytes
HTML transferred: 293940 bytes
Requests per second: 2856.33 [#/sec] (mean)
Time per request: 1.400 [ms] (mean)
Time per request: 0.350 [ms] (mean, across all concurrent requests)
Transfer rate: 41609.21 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.4 0 1
Processing: 0 1 0.6 1 2
Waiting: 0 1 0.6 1 2
Total: 0 1 0.7 1 2
Percentage of the requests served within a certain time (ms)
50% 1
66% 1
75% 2
80% 2
90% 2
95% 2
98% 2
99% 2
100% 2 (longest request)
httperf
- abよりも多少高機能なCLIの負荷テストツール
- 外部ファイルに記載の一連のURLに対してリクエストすることも可能らしい(未確認)
httperf (公式)
httperf(1) - Linux man page
実行例
httperf --server localhost --port 8080 --uri /examples/jsp --num-conns 5 --num-calls 4
オプション例
オプション | 意味 |
---|---|
--num-conns 数 | ユーザあたりのリクエスト数 |
--num-calls 数 | 並列数 |
結果例
Maximum connect burst length: 1
Total: connections 5 requests 20 replies 20 test-duration 0.201 s
Connection rate: 24.8 conn/s (40.3 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 1.3 avg 1.6 max 2.0 median 1.5 stddev 0.3
Connection time [ms]: connect 0.1
Connection length [replies/conn]: 4.000
Request rate: 99.4 req/s (10.1 ms/req)
Request size [B]: 74.0
Reply rate [replies/s]: min 0.0 avg 0.0 max 0.0 stddev 0.0 (0 samples)
Reply time [ms]: response 0.4 transfer 0.0
Reply size [B]: header 99.0 content 0.0 footer 0.0 (total 99.0)
Reply status: 1xx=0 2xx=0 3xx=20 4xx=0 5xx=0
CPU time [s]: user 0.19 system 0.02 (user 92.9% system 7.9% total 100.8%)
Net I/O: 16.8 KB/s (0.1*10^6 bps)
Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0
Siege
- abよりも多少高機能なCLIの負荷テストツール
- 外部ファイルに記載の一連のURLに対してリクエストすることも可能
Joe Dog Software > Siege Home (公式)
Github (公式)
siege(1) - Linux man page
↓Cygwinでうまくmakeできず確認中
実行例
オプション例
結果例
Locust
- Pythonで書かれた負荷試験ツール
- シナリオをスクリプトで記述する
- 分散テストにも対応
- WebベースのUIで負荷試験をコントロール(実行・回数指定など)ができる
Locust (公式)
Locust Documentation (公式)
例はいったん割愛
Tsung
- Erlang製の負荷試験ツール
- 複数のプロトコル、分散テストに対応
- レコーダを使用してシナリオを作ることも可能(GUIはなし)
- 出力結果はWeb画面で閲覧可能
Tsung (公式)
Tsung Documentation (公式)
例はいったん割愛
Gatling
- Scalaで書かれた負荷試験ツール
- Enterpriseサポートもある
- JMeterとの比較はこの辺を参照
- JMETER VS GATLING TOOL
- 少し古い記事だがこの段階で見ると明確にJMeterに優位性がある
- どうしてもテストをスクリプトで記載したい、サポートが必要ということがなければJMeterを使うほうがよさそう
- JMETER VS GATLING TOOL
Gatling (公式)
Gatling Documentation (公式)
例はいったん割愛
その他Load ImpactやBlazeMeterなどSaasのツールやHP LoadRunnerといったお高めのものもあるが割愛
用語について
負荷試験に関連する用語とJMeterでの設定との話
用語 | 説明 | JMeterでは |
---|---|---|
スループット | 性能指標の一つ、単位時間あたりの処理量 | - (変わりなし) |
レイテンシ | 性能指標の一つ、クライアントがリクエストしてからレスポンスを受け取るまでの時間 | - (変わりなし) |
クライアント・ユーザ | 1度に1リクエストを発行できるリクエスト生成者 | Thread |
クライアント同時起動数・並列実行数 | 同時にリクエストを発行するクライアント数 | Thread Group > Number of Threads |
Ramp-Up期間 | テスト開始後にすべてのクライアントが起動するまでのウォームアップ期間。ランプアップ期間 | Thread Group > Ramp-up period |
テストシナリオ(狭義) | クライアントが実行する一連のリクエスト | Thread Group内の一連の設定 |
テストシナリオ(広義) | 狭義のテストシナリオに加えクライアント同時起動数やシナリオ実行回数も含む | Test Plan(日本語のテスト計画というイメージより狭いか) |
シナリオ実行回数 | 1クライアントがテストシナリオを繰り返す回数 | Thread Group > Loop Count |
JMeterのTest Planを1つ作成することを日本語で説明するなら、テストシナリオを1つ作成する、と言った方がイメージに近いだろう