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