主要メトリクスの意味
JMeter の Aggregate Report や Summary Report に表示される主要なメトリクスを確認します。
| メトリクス | 説明 | 良い値の目安 |
|---|---|---|
| Average（平均応答時間） | 全リクエストの平均レスポンスタイム（ms） | 用途による。Webページは 1000ms 以下が目安 |
| Median（中央値） | 応答時間の中央値。外れ値の影響を受けにくい | 平均と近ければ分布が安定している |
| 90th Percentile | 90%のリクエストがこの時間以内に完了 | SLA 定義に使用。通常 Avg より 50〜100%程度大きい |
| 99th Percentile | 99%のリクエストがこの時間以内に完了。最悪ケースに近い | SLA の上限値として設定されることが多い |
| Throughput（スループット） | 1秒あたりのリクエスト処理数（req/s） | 高いほど良い。サーバーの処理能力上限が指標 |
| Error %（エラー率） | 失敗したリクエストの割合 | 本番テストでは 0〜0.1% が理想 |
スループットの読み方
スループット（Throughput） は「サーバーが単位時間内に処理できるリクエスト数」を表します。 負荷をかけるにつれてスループットがどう変化するかを観察することが重要です。
典型的なスループットカーブには次のパターンがあります。
| パターン | 意味 | 対応 |
|---|---|---|
| 負荷増加に比例して上昇 | サーバーに余裕がある。処理能力未到達 | さらにスレッドを増やして上限を探る |
| あるスレッド数で頭打ち | サーバーの処理能力に達した。これがサーバーの最大スループット | このスレッド数が設計負荷の基準値になる |
| 負荷増加でスループット低下 | オーバーロード状態。リクエストがキューに溜まっている | アプリやサーバーのボトルネック調査が必要 |
応答時間の分析
平均応答時間だけでなく、パーセンタイル分布 を確認することが重要です。
💡 平均値に騙されないために
例えば「平均 300ms」と報告があっても、99%tile が 5000ms の場合は 1%のユーザーが5秒待たされていることになります。ユーザー体験の評価には 95th または 99th パーセンタイルを使うことを強く推奨します。
応答時間の分析観点：
- 標準偏差（Std. Dev.）が大きい → 応答時間のばらつきが大きい。負荷が高い時間帯に急激に悪化している可能性
- Max が Avg の 10 倍以上 → 外れ値（スパイク）が発生している。GC やDB接続待ちが原因のことが多い
- 負荷増加とともに応答時間が急上昇 → キューイングが発生している。サーバーのスレッドプールや接続数の設定見直しが必要
エラー率の確認と原因特定
エラー率（Error%）が高い場合は、どのリクエストでどのようなエラーが起きているかを 特定する必要があります。
エラーの原因を調べる手順：
- GUI モードで View Results Tree を確認し、失敗したサンプルの Response data タブを確認する
- CLI テストの場合は JTL ファイルを開き、
successがfalseの行を抽出する - レスポンスコード（4xx・5xx）と、アサーション失敗を切り分ける
| エラーの種類 | 主な原因 |
|---|---|
| HTTP 429 Too Many Requests | サーバーのレート制限に引っかかっている。負荷が高すぎる |
| HTTP 500 Internal Server Error | アプリケーションのバグ、DB 接続エラー、メモリ不足など |
| HTTP 503 Service Unavailable | サーバーが過負荷状態。スレッドプールが枯渇している |
| Connection refused | サーバーが応答できない。ポートが閉じているかサービスが停止 |
| Connection timeout | ネットワークの問題、またはサーバーが応答を返せない状態 |
| Assertion failure | レスポンスの内容が期待値と異なる。ビジネスロジックのバグの可能性 |
HTMLダッシュボードレポートの見方
-e -o オプションで生成される HTML レポートには、複数のチャートと詳細テーブルが含まれます。
index.html をブラウザで開くと確認できます。
| セクション | 内容 |
|---|---|
| APDEX Summary | Application Performance Index。1.0 が理想。0.7 以上で「許容」、0.7 未満で要改善 |
| Statistics Table | Aggregate Report と同等の集計表。パーセンタイル・エラー率・スループットを一覧表示 |
| Over Time グラフ | 応答時間・スループット・エラー数の時系列グラフ。テスト中の傾向変化を視覚的に確認できる |
| Response Times Distribution | 応答時間のヒストグラム。正規分布に近いか、裾が重いかを確認する |
| Response Time Percentiles | 各パーセンタイルの応答時間をグラフ表示 |
| Active Threads Over Time | テスト中のスレッド数の推移。ランプアップが正しく機能しているかを確認 |
✅ APDEX（Application Performance Index）について
APDEX はユーザー満足度を 0〜1 のスコアで表すメトリクスです。「Tolerated（許容）」と「Satisfied（満足）」の閾値を設定（デフォルトは 500ms / 1500ms）し、各レスポンスが満足・許容・不満のどれに分類されるかで計算します。JMeter の HTML レポートでは jmeter.reportgenerator.apdex_satisfied_threshold プロパティで閾値を変更できます。
ボトルネック特定のアプローチ
テスト結果から問題が見つかった場合、JMeter の結果だけでボトルネックを特定するのは困難です。 サーバーサイドの監視ツールと組み合わせて原因を掘り下げる必要があります。
| 問題の症状 | 調査する観点 |
|---|---|
| 応答時間が急増する | サーバーのCPU使用率・メモリ使用率・スレッドプールの状態を確認 |
| エラーが急増する | アプリのエラーログ・DBの接続数上限・スレッドプールの枯渇を確認 |
| スループットが頭打ちになる | アプリケーションの並行処理数上限・DBクエリのボトルネック・ネットワーク帯域幅を確認 |
| 特定のエンドポイントのみ遅い | そのエンドポイントのDBクエリ・外部API呼び出し・ビジネスロジックを重点調査 |
代表的なサーバー監視ツールとしては、Prometheus + Grafana（メトリクス）、 Datadog、New Relic（APM）、 Java VisualVM（JVMプロファイリング）などがあります。 JMeter の Backend Listener を使えば、テスト実行中のメトリクスを Grafana ダッシュボードにリアルタイム表示することも可能です。