Performance Testing Service (PTS) のストレステストが完了すると、PTS はテストデータを自動的に収集し、レポートを生成します。レポートは、シナリオレベルのメトリクス、サンプラーごとのビジネス詳細、ロードジェネレーターの状態、リクエストレベルのサンプリングログを網羅しており、システムのパフォーマンスを評価し、ボトルネックを特定するために必要なすべての情報を提供します。
前提条件
開始する前に、以下を確認してください。
PTS で JMeter パフォーマンステストが完了していること。レポート一覧では、JMeter レポートに JMeter タグ
アイコンが表示されます。
レポートの開き方
PTS コンソールにログインし、[Performance Test] > [Reports] を選択します。
対象のレポートを見つけ、[Actions] 列の [View Report] をクリックします。
サンプリングログは 30 日間保持されます。この期間を過ぎると、サンプリングログは表示できなくなります。データ損失を防ぐため、保持期間が終了する前にレポートをオンプレミスのデバイスにエクスポートしてください。
レポートのセクション
JMeter パフォーマンステストレポートには、[Business Monitoring]、[Load Generator Monitoring]、[Request Sampling Log]、[JMeter Logs] の 4 つのセクションがあります。
ビジネスモニタリング
[Global Monitoring] > [Business Monitoring] に移動して、シナリオレベルのメトリクスとサンプラーごとの内訳を表示できます。
このビューには、2 つのメトリクスグループが含まれています。
シナリオメトリクスは、テスト実行全体を要約します。
| メトリクス | 説明 |
|---|---|
| VUM | 消費されたリソースの総量であり、仮想ユーザー分 (VUM) で測定されます。1 VUM は、1 仮想ユーザーが 1 分間実行されることに相当します。 |
| シナリオの同時実行数 | アクティブな同時実行仮想ユーザー数。ウォームアップフェーズ中、この値は設定された同時実行数レベルに向かって増加します。ウォームアップが完了すると、設定されたレベルと一致します。 |
| シナリオ TPS (秒) | すべてのエージェントの統計期間におけるリクエスト総数を、その期間の長さ (秒) で割った値です。 |
| リクエスト総数 | シナリオ全体で送信されたリクエストの総数。 |
| 成功 RT 平均 (ミリ秒) | すべての成功したリクエストの平均レスポンスタイム (RT) です。安定した、または低い値は、バックエンドのパフォーマンスが一貫していることを示します。 |
| 失敗 RT 平均 (ミリ秒) | すべての失敗したリクエストの平均 RT です。成功した RT と比較して、失敗がタイムアウトまたは即時拒否と相関しているかどうかを判断できます。 |
| 成功率 | すべてのエージェントにおける成功したリクエストの割合。 |
| 負荷ソース | テストトラフィックの送信元：中国本土内のパブリックインターネット、または Alibaba Cloud VPC。 |
| 指定された IP アドレス | シナリオの負荷設定で構成されたソース IP アドレスの数。 |
ビジネスメトリクスは、個々のサンプラーごとにパフォーマンスを分類します。
| メトリクス | 説明 |
|---|---|
| サンプラー名 | サンプラーの名前、またはシナリオ全体の集計。 |
| リクエスト総数 | このサンプラーによって送信されたリクエストの総数。 |
| 平均 TPS | このサンプラーのリクエスト総数をパフォーマンステスト期間で割って計算された平均 TPS 値です。 |
| 成功率 | このサンプラーの成功したリクエストの割合。成功数または失敗数をクリックすると、対応するログエントリに直接ジャンプできます。[Details] をクリックすると、HTTP ステータスコード (2XX、3XX、4XX、5XX) やその他の例外でグループ化された失敗数が表示されます。[other exceptions] の下で、エラーランキング、エラーメッセージ、およびそれらのパーセンテージ分布を表示できます。 |
| 平均レスポンスタイム | このサンプラーの平均レスポンスタイム。[Details] をクリックすると、最大、最小、およびパーセンタイルのレスポンスタイムが表示されます。 |
| トラフィック (送信/受信) | このサンプラーによって送受信された合計バイト数。 |
ビジネスメトリクスの解釈
これらのパターンを使用して、一般的なパフォーマンスの問題を特定できます。
負荷が増加してもレスポンスタイムが横ばい：システムは負荷を適切に処理しています。これは、正常なサービスで期待されるパターンです。
TPS が安定している状態でレスポンスタイムが上昇：バックエンドが飽和状態に近づいています。リソースをスケールするか、遅いエンドポイントを最適化してください。
同時実行数が増加しても TPS が頭打ち：ボトルネックが存在します。アプリケーション、データベース、またはネットワーク層の可能性があります。最も遅いサンプラーを手がかりとして確認してください。
成功率の低下：失敗したリクエストが増加しています。[Details] を使用して HTTP ステータスコード別にエラーをグループ化し、根本原因 (例：レート制限の場合は 429、サービス過負荷の場合は 503) を特定してください。
ロードジェネレーターモニタリング
[Global Monitoring] > [Load Generator Monitoring] に移動して、テストトラフィックを生成しているマシンの状態を確認できます。
モニタリングビューには、各ロードジェネレーターの場所、ネットワーク帯域幅、CPU 使用率、およびメモリ使用量が表示されます。これらのメトリクスを監視して、ロードジェネレーター自体がテスト結果を歪める可能性のあるボトルネックにならないようにしてください。
リクエストサンプリングログ
[Request Sampling Log] をクリックし、任意のリクエストの [View Details] をクリックして、その [General] 情報と [Timing Waterfall] を検査してください。
サンプリングログは、個々のリクエストの失敗をデバッグするのに役立ちます。[Timing Waterfall] は、各リクエストフェーズで時間がどこで費やされているかを視覚化し、遅いステージを簡単に見つけることができます。
JMeter ログ
[JMeter Logs] をクリックして、JMeter エンジンのログ出力を表示および取得できます。
[JMeter Logs] タブで、フィルターバーを使用して [Log Level]、[Time Range]、および [Stress Thread] で検索してください。別の [Load Generator ID] を選択して、そのロードジェネレーターからのログを表示してください。ログエリアには、バージョン、Java 環境、オペレーティングシステム、メモリ、プロセッサ数、ロードされた JMX ファイルなど、JMeter の起動と初期化の詳細が表示されます。
JMeter ログを使用して、誤って設定されたスレッドグループ、プラグインエラー、またはビジネスメトリクスに現れないアサーションの失敗など、スクリプトレベルの問題のトラブルシューティングを行ってください。
モニタリングデータは Backend Listener を通じて収集されます。エージェントのサンプリング期間とデータ集計期間はどちらも 15 秒であるため、メトリクスはリアルタイムの状況と比較してわずかな遅延を反映する場合があります。
一般的な問題のトラブルシューティング
| 現象 | 考えられる原因 | アクション |
|---|---|---|
| 5XX コードの高いエラー率 | バックエンドサービスの過負荷またはクラッシュ | アプリケーションログを確認し、バックエンドリソースをスケールしてください。 |
| 4XX コードの高いエラー率 | 不正なリクエストパラメーターまたは認証の問題 | サンプリングログでサンプラーの設定とリクエストヘッダーを確認してください。 |
| テスト開始時のレスポンスタイムの急上昇 | コールドスタート、キャッシュミス、または接続プールの初期化 | 最初に短いウォームアップテストを実行するか、分析からウォームアップフェーズを除外してください。 |
| ロードジェネレーターの CPU が高い | ジェネレーターが過負荷状態 | より多くのジェネレーターに負荷を分散させるか、ジェネレーターあたりの同時実行数を減らしてください。 |
| メトリクスに予期しない遅延が表示される | 15 秒の集計ウィンドウ | これは想定される動作です。結論を出す前に、少なくとも 2 つの集計サイクルを待ってください。 |
次のステップ
テストメトリクス：すべての PTS メトリクスとその定義の完全なリファレンス。
パフォーマンステストの技術ガイド：ストレステストの設計と実行に関するベストプラクティス。
テスト分析とチューニング：結果の解釈とシステムパフォーマンスの最適化に関するガイダンス。