• 戻る（JmeterによるWebアプリの負荷テスト）
  • Apache Jmeter
    • Jmeter用語
    • Jmeterのインストール
    • Jmeterによる3層C/Sの負荷テスト
    • Jmeterによる可変値の追跡
    • Jmeterの正規表現
  • Jmeterの結果のレポーティング

負荷テスト結果のレポーティング方法

補足（レポーティングの前に決めること）: 本ページは
「どう出力するか」を扱うが、実務ではその前に
**「何を合格とするか」**を決めておく必要がある。

指標	典型的な合格基準の書き方
応答時間	平均ではなく 90%tile / 95%tile で規定する
エラー率	0.1% 未満 など
スループット	目標 TPS を満たすこと
リソース	CPU 70% 未満、GC 時間 10% 未満 など

平均値を基準にしてはいけない。
応答時間の分布は正規分布ではなく
**右に長く裾を引く（少数の極端に遅いリクエストがある）**ため、
平均は実際のユーザ体験を表さない。
後述の「統計レポート」に 90% / 95% / 99% Line が
用意されているのはこのためである。

ここでは、各種レポーティング用のリスナーの設定を行うが、

• リソースの消費量が大きい、
  機能テスト、デバッグ・検証用のリスナーの設定を変更し、
• また、負荷テストのレポート用のリスナーを追加する。

スクリプトのデバッグ時に追加したリスナーの設定を変更する。

無効化する。

「エラーログ(XML)」の出力を構成する。

• ファイル名
  time 関数を使用して、以下のように指定（フルパス）。

  "...\XXXXシナリオ・エラーログ_${__time(YMDHMS)}.jtl"
  

• 「エラーログのみ」にチェックを入れる。

• config（Sample Result Save Configurationの出力項目を設定）

  • config ボタンを押下して、
  • XML で保存するように変更して（［Save as XML］チェック・ボックスにチェックを入れる）、
  • 全列にチェックを入れる。

移行メモ（正誤）: 原典のファイル名指定は
&{__time(YMDHMS)} と .jlt になっていたが、

• JMeter の関数記法は ${...}（&{...} ではない）
• 結果ログの拡張子は .jtl（JMeter Test Log。.jlt ではない）

であるため修正した。
原典中の他の箇所も同様に .jlt と記載されている。

「テスト計画」以下に負荷テストのレポート用のリスナーを追加。

「テスト計画」以下に「統計レポート」リスナーを追加し、
「統計ログ(CSV)」の出力を構成する。

• ファイル名
  time 関数を使用して、以下のように指定（フルパス）。

  "...\XXXXシナリオ・統計レポート_${__time(YMDHMS)}.jtl"
  

• config（Sample Result Save Configurationの出力項目を設定）

  • config ボタンを押下して、
  • CSV で保存するように変更して（［Save as XML］チェック・ボックスのチェックを外す）、
  • 全列にチェックを入れる。

補足（なぜエラーは XML、統計は CSV なのか）: この使い分けには理由がある。

用途	形式	理由
エラーログ	XML	リクエスト／レスポンスのヘッダと本文を保存できるのは XML のみ。原因究明にはこれが要る
統計ログ	CSV	全件を記録するためサイズと書き込み負荷が支配的。CSV が圧倒的に軽い

全件を XML で残すと、長時間テストでは
ログ出力自体がボトルネックになり、
ディスクも数 GB 単位で消費する。
「エラーのみ XML（本文つき）＋ 全件 CSV（本文なし）」の
組み合わせが定石である。

項番	統計ログ(CSV)	エラーログ(XML)	チェック項目名	プロパティ名	説明
1		◯	Save as XML	jmeter.save.saveservice.output_format	xml、csv、db からフォーマットを指定。 現在、xml と csv のみがサポート。
2	◯		Save Field Names (CSV)	jmeter.save.saveservice.print_field_names	CSV ヘッダのフィールド名。 ※ CSV 形式のみ。
3	◯		－	jmeter.save.saveservice.default_delimiter	CSV の区切り文字。 ※ CSV 形式のみ。
4	◯		－	jmeter.save.saveservice.timestamp_format	タイムスタンプ形式 none, ms, yyyy/MM/dd HH:mm:ss.SSS ※ CSV 形式のみ。

補足（timestamp_format は ms のままが無難）: 既定の ms（エポック ミリ秒）は
人間には読めないが、Excel やツールでの再集計が容易であり、
ダッシュボード レポート（-g）が要求する形式でもある。
日付書式に変えると -g でのレポート生成が失敗することがあるため、
変更する場合は
jmeter.save.saveservice.timestamp_format と
レポート生成側の設定を合わせること。

当該フィールドを保存する場合は true。保存しない場合は false。

• GUI（Sample Result Save Configuration ダイアログ）表示あり

項番	統計ログ(CSV)	エラーログ(XML)	チェック項目名	プロパティ名	説明	ログ上の項目名
2	◯	◯	Save Time Stamp	sampleresult.timestamp.start	サンプラーを実行した時刻	timeStamp
3	◯	◯	Save Elapsed Time	jmeter.save.saveservice.time	レスポンス時間	elapsed
4	◯	◯	Save Label	jmeter.save.saveservice.label	サンプラーのラベル	label
5	◯	◯	Save Response Code	jmeter.save.saveservice.response_code	HTTP レスポンスステータスコード	responseCode
6	◯	◯	Save Response Message	jmeter.save.saveservice.response_message	HTTP レスポンスステータスコードに対応するメッセージ	responseMessage
7	◯	◯	Save Thread Name	jmeter.save.saveservice.thread_name	スレッド名	threadName
8	◯	◯	Save Data Type	jmeter.save.saveservice.data_type	レスポンス・データのタイプ	dataType
9	◯	◯	Save Success	jmeter.save.saveservice.assertion_results	真または偽 ※ none, first, all	success
10	◯	◯	Save Assertion Failure Message	jmeter.save.saveservice.assertion_results_failure_message	※ CSV 形式のみ。	failureMessage
11	◯	◯	Save received byte count	jmeter.save.saveservice.bytes	サンプルの受信バイト数	bytes
12	◯	◯	Save sent byte count	jmeter.save.saveservice.sent_bytes	サンプルの送信バイト数	sentBytes
13	◯	◯	Save Active Thread Counts	jmeter.save.saveservice.thread_counts	スレッドグループ内のアクティブなスレッド数と テスト計画内のアクティブなスレッド数	grpThreads, allThreads
14		◯	Save URL	jmeter.save.saveservice.url	URL	URL
15		◯	Save Response Filename	jmeter.save.saveservice.filename	ファイル名	Filename
16	◯	◯	Save Latency	jmeter.save.saveservice.latency	レイテンシ	latency
17	◯	◯	Save Connect Time	jmeter.save.saveservice.connect_time	接続を確立する時刻	connect
18			Save Encoding	jmeter.save.saveservice.encoding	エンコーディング	encoding
19			Save Sample and Error Counts	jmeter.save.saveservice.sample_count	サンプル数とエラー数	SampleCount, ErrorCount
20			Save Hostname	jmeter.save.saveservice.hostname	サンプルが生成された場所（ホスト名）	Hostname
21	◯	◯	Save Idle Time	jmeter.save.saveservice.idle_time	サンプリングに費やされなかった時間	IdleTime
22		◯	Save Request Headers (XML)	jmeter.save.saveservice.requestHeaders	Request Header	CSV 形式ではサポートされない
23		◯	Save Request Data (XML)	jmeter.save.saveservice.samplerData	Sampler Data	同上
24		◯	Save Response Headers (XML)	jmeter.save.saveservice.responseHeaders	Response Header	同上
25		◯	Save Response Data (XML)	jmeter.save.saveservice.response_data	Response Data	同上
26		◯	Save Sub Results (XML)	jmeter.save.saveservice.subresults	Transaction Controller の結果	同上
27		◯	Save Assertion Results (XML)	jmeter.save.saveservice.assertions	Assertion 結果	同上

移行メモ（体裁）: 原典の表は項番が 2 から始まって おり、
項番 1 の行が存在しない。原典どおりとした（欠番）。
また、原典では末尾 2 列が
「CSV Log format」「XML Log format」の 2 列だったが、
ほぼ全行で結合（|>|）されていたため
「ログ上の項目名」1 列に統合した。
各形式の詳細は下記を参照。

• CSV Log format
  http://jmeter.apache.org/usermanual/listeners.html#csvlogformat
• XML Log format 2.1
  http://jmeter.apache.org/usermanual/listeners.html#xmlformat2.1

補足（elapsed と latency と connect の違い）: この 3 つの関係は
ボトルネックの切り分けに直結するため、正確に理解しておきたい。

送信開始 ──[connect]── 接続確立 ── 要求送信 ── 最初の1バイト受信 ── 最後の1バイト受信
         └─────────── latency ──────────────────┘
         └─────────── elapsed ─────────────────────────────────────┘

項目	意味	大きいときに疑うもの
connect	TCP（+ TLS）の接続確立まで	ネットワーク、TLS ハンドシェイク、コネクション枯渇
latency	最初の 1 バイトが返るまで（TTFB）	サーバ側の処理時間（アプリ・DB）
elapsed	応答を受け切るまで	上記＋転送量／帯域

つまり、

• latency が大きい → サーバ内部が遅い
  （SQL Server 問題の分析方法、
  因果関係の分析例へ）
• elapsed - latency が大きい → レスポンスが大きい／帯域が細い
• connect が大きい → 接続まわり（KeepAlive 無効、TLS、DNS）

という切り分けができる。
Save Connect Time と Save Latency は必ず有効にしておくこと。

• GUI（Sample Result Save Configuration ダイアログ）表示なし

項番	プロパティ名	説明	ログ上の項目名
1	jmeter.save.saveservice.response_data.on_error	Save ResponseData for failed samples	－
2	sample_variables	JMeter 変数名のオプションリスト	Variables（CSV）

補足: jmeter.save.saveservice.response_data.on_error=true は、
失敗したサンプルのレスポンス本文だけを保存する設定で、
「全件 CSV は軽く保ちたいが、エラーの中身は見たい」という
要求に対する最も実用的な折衷案である。
前掲の「エラーのみ XML」と併せて覚えておくとよい。

sample_variables は、CSV の末尾に
任意の JMeter 変数の値を列として追加するもので、
「どのユーザ ID・どのデータで失敗したか」を
後から突き合わせるのに使う
（Jmeterによる可変値の追跡）。

統計ログ(CSV)をベースに生成される。

項番	項目名	説明
1	Label	サンプルのラベル。 "ラベルにグループ名を含める？" が選択されると、スレッドグループの名前が接頭辞として追加される。 これにより、必要に応じて異なるスレッドグループの同一ラベルを個別に照合することができる。
2	# Samples	ラベルのサンプル数。
3	Average	ラベルのレスポンス時間の平均値
4	Median	ラベルのレスポンス時間の中央値
5	90% Line	ラベルのレスポンス時間の 90% パーセンタイル（90% に位置する値）
6	95% Line	ラベルのレスポンス時間の 95% パーセンタイル（95% に位置する値）
7	99% Line	ラベルのレスポンス時間の 99% パーセンタイル（99% に位置する値）
8	Min	ラベルのレスポンス時間の最短時間
9	Max	ラベルのレスポンス時間の最長時間
10	Error %	ラベルのレスポンスのエラーの割合
11	Throughput	ラベルのリクエスト数 / (秒 or 分 or 時間)。 時間単位は、表示されたレートが少なくとも 1.0 になるように選択される。 CSV ファイルに保存されると、秒が選択される。
12	Received KB/sec	ラベルの受け取ったキロバイト/秒で測定されたスループット
13	Sent KB/sec	ラベルの送信されたキロバイト/秒で測定されたスループット

補足（この表の読み方）: 数字の並びから状態を読む観点は次のとおり。

見るもの	意味するところ
Average と Median の乖離	大きいほど分布が歪んでいる（一部が極端に遅い）
90% Line と Max の乖離	稀に極端な外れ値がある。GC、ロック待ち、リトライを疑う
Error % > 0	まず原因を潰す。エラーは速く失敗するため、放置すると応答時間が良く見える
Throughput が頭打ちで応答時間だけ伸びる	飽和点を超えている。これ以上多重度を上げても意味が無い

最後の点が特に重要で、
スループットが頭打ちになった時点が、そのシステムの限界である。
そこから先は待ち行列が伸びるだけで、応答時間だけが悪化する。
負荷テストの目的の一つはこの飽和点を見つけることにある。

なお、Error % が高い状態の応答時間には意味が無い
（エラー応答は速いため、平均を押し下げる）。
エラーを潰してから性能を語るのが順序である。

テストの成功を確認するための簡易確認用の HTML レポートを生成する機能。

• 以下のコマンドで統計ログ(CSV)をベースに生成される。

  jmeter -g "XXXXシナリオ・統計レポート_XXXX.jtl" -o 出力先フォルダ
  

• 以下のプロパティを設定する。
  http://jmeter.apache.org/usermanual/generating-dashboard.html#configuration

http://jmeter.apache.org/usermanual/generating-dashboard.html#overview

補足（テスト実行と同時に生成する）: -g は
既存の JTL からレポートだけを作り直す用途である。
通常はテスト実行と同時に生成すればよい。

jmeter -n -t test.jmx -l result.jtl -e -o report

ダッシュボードには次が含まれ、
本ページの「Excel でグラフを生成」で手作業していた内容を
ほぼ置き換えられる。

セクション	内容
APDEX	満足度指標（閾値は jmeter.reportgenerator.apdex_* で設定）
Statistics	前掲の統計レポート相当（パーセンタイル込み）
Errors	エラーの種類別集計
Over Time	応答時間・スループット・アクティブスレッド数の時系列
Throughput	秒あたりのヒット数、応答コード別
Response Times	分布、パーセンタイル、負荷との相関

注意点として、

• -o のフォルダは空でなければエラーになる。
• GUI モードのリスナーが出力した JTL では失敗することがある
  （必要な列が欠けているため）。
  -l で出力した JTL を使うのが確実である。
• Ramp-up 中や終了間際のデータを除外したい場合は
  jmeter.reportgenerator.start_date /
  end_date プロパティで期間を絞れる。
  定常状態のみを評価するために有用である。

出力ファイルのデータは、ワークベンチの適切なリスナーにロードして分析する。

補足: 前掲のとおり ワークベンチは JMeter 4.0 で廃止された。
現在は GUI を起動し、
テスト計画に置いたリスナーの「ファイル名」欄に
既存の JTL を指定すれば読み込める（テストの実行は不要）。

統計ログ(CSV)をベースに生成される。

• 統計ログ(CSV)のファイルパスを指定する。
• Interval を指定して、［Apply interval］ボタンを押下する。
• サンプラーのラベルを正規表現で記入して、［Apply filter］ボタンを押下する。
• ［Display Graph］ボタン ---> ［Save Graph］ボタンを押下する。

統計ログ(CSV)をベースに生成される。

項番	グラフ名	縦軸	横軸
1	多重度（仮想ユーザ数）の推移	grpThreads or allThreads	timeStamp
2	エラー件数の推移	success=false	timeStamp
3	レスポンス時間の推移	elapsed	timeStamp

補足（この 3 つを「同じ横軸で重ねる」ことに意味がある）: 3 つとも横軸が
timeStamp である点が要点である。
別々に見るのではなく重ね合わせることで、
次のような読み取りができるようになる。

観察されるパターン	示唆
多重度の増加に比例して応答時間が伸びる	飽和点を超えている
多重度は一定なのに途中から応答時間が伸びる	蓄積性の問題。メモリリーク、コネクション枯渇、ログ肥大、DB の統計情報劣化
応答時間が周期的に跳ねる	GC、チェックポイント、バッチ、キャッシュ期限切れ
エラーが増えると同時に応答時間が下がる	速く失敗しているだけ（前掲）

特に 2 番目の「時間とともに悪化する」パターンは、
短時間のテストでは絶対に見つからない。
耐久試験（数時間〜数日）が必要な理由がここにある
（メモリ リーク、
因果関係の分析例）。

さらに、これらのグラフにサーバ側のメトリクス
（CPU、メモリ、ディスク I/O、GC 時間）を同じ時間軸で重ねると、
原因の特定が一気に容易になる。
現在はこれを Backend Listener + InfluxDB + Grafana で
リアルタイムに行うのが一般的である
（パフォーマンス カウンタ）。

• 12.1 Default Configuration
  http://jmeter.apache.org/usermanual/listeners.html#defaults
• 12.1.2 Sample Result Save Configuration
  http://jmeter.apache.org/usermanual/listeners.html#sample_configuration

http://jmeter.apache.org/usermanual/generating-dashboard.html

---

Tags: 移行, テスト, ツール類