ストレステスト結果の分析

世界には毎日、ストレステストを実行するためのツールがますます増えています。実際、このトピックへの関心は高まり始めています。

負荷テストツールの主なタスクは、特定の負荷をシステムに適用することです。しかし、これに加えて、この負荷の提出の結果に関するレポートを提供するという、それほど重要ではないもう1つのタスクがあります。それ以外の場合はテストを実施しますが、その結果については何も言えず、システムの劣化がいつから始まったのかを正確に判断することはできません。



現時点で最も人気のあるテストツールは、Gatling、MF LoadRunner、ApacheJMeterです。それらはすべて、実行されたテストに関する既製のレポート、およびレポート自体の作成に基づいた個々のグラフまたは生データを生成する機能を備えています。







レポートを作成する前に、私たちが誰のためにレポートを作成し、どのような目的を追求しているかを理解する必要があります。メモリリークがあるかどうかを判断することが目的である場合、信頼性テスト中に不安定な操作が修正された場合、または回帰テストの一部として2つのリリースを相互に比較する必要がある場合は、各操作のレポートにアプリケーション応答時間のグラフを多数追加しても意味がありません。もちろん、問題を修正して理解したくない場合を除いて、これらの質問に答えるのに必要なグラフは2、3だけです。したがって、レポートを作成する前に、本当にすべてのグラフをレポートに追加する必要があるのか​​、それとも最もわかりやすいグラフのみを追加する必要があるのか​​を考えて、テストの目的に答えてください。また、グラフのセットとレポートの分析は、選択した負荷モデル（閉じているか開いているか）によって異なります。モデルが異なれば、チャート上で異なる数値が得られるからです。



Tinkoffではガトリングツールを積極的に使用しているため、その例を使用して、夢のレポートを作成する方法と、それを分析するときにどこを見ればよいかを説明します。また、この記事で説明されているほとんどすべてのチャートは、Grafanaにツールのバンドルを使用してオンラインで取得できることにもすぐに注意したいと思います。これは、事前構成されたダッシュボードを使用してその場でレポートを作成するための最も便利なツールです。さらに、送信したデータに基づいて、ほぼすべてのグラフをより迅速に作成できます。ほぼすべての負荷テストツール用の既製のダッシュボードがすでにあります。他のツール（MFLoadRunnerおよびApacheJMeter）のグラフも提供され、それらの分析はGatlingとの類推によって構築されます。

基本的な指標

指標

グループごとの要求応答時間の定量的およびパーセンテージ分布を示します。このタイプのチャートは、残りのチャートを詳細に分析することなく、テスト結果の迅速な予備評価を行うために使用すると便利です。



グループ間のしきい値は、ピアレビューまたはSLA（非機能要件）に基づいて事前定義されています。たとえば、次の3つのグループがあります。

• 優れた-50秒未満の応答時間。
• 中-50秒以上100秒未満。
• ひどい-100秒以上。

Gatlingでは、gatling.confファイルでグループ間を移動するためのしきい値とその数を自分で構成できます。方法論に基づいて、このタイプのチャートを作成することをお勧めします。APDEX（アプリケーションパフォーマンスインデックス）

失敗したリクエストの数/パーセンテージを示すインジケーターを追加することもできます。







APDEXメソッドを使用すると、回帰テストでインジケーターを使用してリリースを比較できます。これにより、リリースが一般的にどれだけ悪化または改善したかをすぐに確認できます。残念ながら、このグラフはMFLoadRunnerとApacheJMeterですぐに使用できるものではありませんが、Grafanaダッシュボードを使用して簡単に作成できます。

応答時間表

デフォルトでは、Gatlingは、百分位数、平均および最大応答時間、およびエラーに基づいてスプレッドシートを作成します。SLA（非機能要件の超過）を超えて追跡します。通常、SLAは、パーセント95、99、およびエラーのパーセンテージを示します。したがって、この表を使用すると、テスト結果をすばやく評価できます。



クエリをトランザクションとしてグループ化すると、個々のクエリのスコアと、グループ全体およびトランザクションのスコアの両方を一度に表で確認できます。

仮想ユーザーチャート

通常、分割して測定され、ユーザーがアプリケーションに入る方法を示します。これにより、実際の負荷プロファイルが示されます。 MF LoadRunnerとGatlingの場合、これらのグラフは仮想ユーザーの数を示し、ApacheJMeterの場合はスレッドの数を示していることにすぐに注意してください。



グラフは、負荷アプリケーションの正確さを制御するために使用されます。設計シナリオは、実際にシステムに提出したものと一致している必要があります。たとえば、チャートで計画されたシナリオからの大きな上方への逸脱が見られる場合は、何かがうまくいかなかったことを意味します。計算のエラー、ロードツールのコピーが必要以上に起動されたなどです。計画よりも100人多くのユーザーを申請し、システムは元々10人のユーザーのみで動作するように設計されていたため、さらにグラフを分析しても意味がないかもしれません。

このグラフは2つのタイプに分けられます。

• Active Usersは、1秒あたり現在アクティブなスレッドの数を表示します。特にオープンロードモデルでは、スレッドが開始および停止すると、このレートはテスト全体で変動します。
• Total VUsersは、テストの開始以降に開始および停止したスレッドの総数を示します。スレッドが停止しないクローズドロードモデルに便利です。

グラフのタイプは、負荷モデルによっても異なります。

• クローズドモデル-ユーザーは、計画された負荷プロファイルに従ってシステムにログインする必要があります。グラフにディップまたはピークが表示されている場合、これは、負荷が計算または計画されたシナリオに従って進まなかったことを示しており、さらに調査する必要があります。
• — , . , . , , / . , — .

Response Time

ほとんどの場合、ミリ秒単位で測定されます。これは、アプリケーションへの要求に対する応答時間を示します。応答時間はSLAを超えてはなりません。このグラフは、負荷テスト中に劣化点を見つけるための主要なツールです。



グラフにピークが表示されている場合は、その時点でアプリケーションが何らかの理由で応答しなかったことを意味します。これは、さらなる調査の開始点になる可能性があります。応答時間は均一で、負荷ステップ全体のすべての操作でピークがなく、負荷のエントレインメントとも相関している必要があります。ガトリングには、他のツールとは異なり、「ネット」（平均、集計されていない）応答時間のグラフは含まれていません。



各リクエストの応答時間のグラフに加えて、合計応答時間（合計応答時間）の線を表示すると便利です。加えられた負荷（VU / RPS）プロットをオーバーレイすることにより、加えられた負荷（VU / RPS）の増加による応答時間の増加との相関関係を追跡できます。Apache JMeterは、このグラフを応答時間とスレッドと呼びます。



次に、グラフがあり、その上に多くの線があり、それぞれが独自のシナリオまたは要求を表示します。多くの操作と非線形プロファイルを含む複雑なテストがある場合は、最も代表的なクエリまたはクエリのグループのみをレポートに表示することをお勧めします。または、スケジュールとレポートが乱雑にならないように、SLA / SLOを超えるリクエストのみを反映することもできます。

グラフのバリエーション

応答時間の百分位数が適用され、すべての要求の平均応答時間の行が追加される変更が可能です。平均応答時間は鋭いピークに非常に敏感であるため、ここでパーセンタイルを使用する方が正確です。



パフォーマンステストでは、わかりやすくするために95パーセンタイルと99パーセンタイルが最もよく使用されます。ただし、平均応答時間を見る場合は、標準偏差（ルート平均二乗）を考慮する必要があります。

応答時間の分布

時間の分布がリクエスト数に依存していることを示す優れたグラフもあります。



この種のチャートはインジケーターにいくぶん似ていますが、百分位数やその他の集計によってクリッピングされることなく、時間の分布のより完全な全体像を示しています。チャートを使用すると、インジケーターのグループの境界をより明確に定義できます。MFLoadRunnerにはそのようなスケジュールはありません。

Latency

このメトリックから、追加のパラメーターLatency（milliseconds）も区別できます-待ち時間（ほとんどの場合、これはネットワーク待ち時間として理解されます）。このパラメータは、要求の送信が終了してから最初の応答パケットがシステムから受信されるまでの時間を示します。

このパラメータを使用すると、パラメータが大きくなった場合にネットワークレベルでレイテンシを測定することもできます。ゼロになる傾向があることが望ましい。このタイプと次のタイプのグラフは、主に詳細な分析とパフォーマンスの問題の検出に使用されます。このグラフは、ガトリングですぐに使用できるものではありません。MF LoadRunnerでは、監視エージェントをインストールしている場合、このグラフはNetwork VirtualizationGraphsブロックのAverageLatencyGraphと呼ばれます。

帯域幅

上記のメトリックと同様に、Bandwidthパラメーター（キロビット/秒）（チャネル帯域幅）を選択できます。単位時間あたりに転送できるデータの最大量を示します。



ロードツールでこのパラメータを変更することにより、アプリケーションへのさまざまな接続ソース（4Gモバイルネットワークまたは有線ネットワーク）をシミュレートできます。Gatlingの無料バージョンにはこのチャートがなく、GatlingFrontLineの有料バージョンでのみ利用できます。このグラフは、MF LoadRunnerでのみ使用可能で、Latencyと同じブロックにあり、平均帯域幅使用率グラフと呼ばれます。

1秒あたりのリクエストチャート

1秒あたりのピース数で測定-1秒間にシステムに入るリクエストの数を示します。



このグラフは、負荷がかかった状態でシステムが処理できるリクエストの数を示しており、レポートを作成するためのメイングラフでもあります。また、劣化点または局所的な極値を通過するときに負荷が増加すると、障害が観察され、その後急激に増加するため、SLAを超えて追跡します。ほとんどの場合、これは、アプリケーションが劣化し始めると、リクエストがアプリケーションの入り口にも蓄積され始め（キューが表示され）、アプリケーションが何らかの応答を返すか、タイムアウトによってリクエストが減少するため、グラフが急激に増加するためです-答えを受け取ったからです。

1. VU, RPS/TPS , .
2. Response Time, , .

TPS

1秒あたりのピース数で測定され、1秒間のトランザクション数（トランザクション内に多数の要求が存在する可能性があります）を示します。



たとえば、「個人アカウントの入力」トランザクションには、メインページを開く、ログイン、パスワードを入力する、「送信」ボタンを押す、ウェルカムページにリダイレクトする、単位時間あたりのリクエストが含まれます。Gatlingでは、グラフはGrafanaを使用してのみ取得できます。これは、HTMLレポートのグループの場合、グラフは応答時間によってのみ作成されるためです。

エラーチャート

通常、レート（1秒あたりのピース数）で測定されます。グラフは、誤った要求の数の増加を示しています。リクエストの総数に対するパーセンテージとして値を測定することも便利です。このグラフは、エラーの数または割合によってSLA制限からの脱却を追跡します。



応答時間グラフをオーバーレイすると、エラーの増加がアプリケーションの応答時間の増加にどのように影響するかを確認できます。



デフォルトでは、ガトリングにはエラーのみを示す個別のグラフはありません。ガトリングでは、VUグラフと組み合わされ、負荷の増加がエラー数の増加にどのように影響するかを即座に示し、SLAを超えたりエラーが発生したりするしきい値を検出するのに役立ちます。Apache JMeterにも個別のスケジュールはなく、トランザクション数のグラフと組み合わされています。

HTTP応答ステータス

アプリケーションの応答コードごとにエラー数の分布をグラフにプロットすることもできます。エラーの分類に使用すると便利です。



たとえば、前のグラフで100％を取得した場合、サーバーが応答しないために発生した50xエラー、またはプールが間違っていてユーザーがログインできないために発生した403エラーの分析を開始します。 HTTPプロトコルを使用しています。

当初、無料版のGatlingにはこのチャートがなく、有料版のGatlingFrontLineでのみ利用できます。グラフを無料バージョンで表示するには、ログがグレイログに収集されるようにlogback.xmlを再構成し、その中に目的のグラフを作成する必要があります。

スループットグラフ

通常、1秒あたりのビット数で測定されます。グラフは、アプリケーションのスループット、つまり、単位時間あたりにアプリケーションによって送信および処理されたデータの量を示します。

これは通常、アプリケーションの問題の詳細な分析に使用されます。ガトリングにはこのグラフがFrontLineにのみ含まれており、無料バージョンには含まれていません。

可能な変更

1. Response Time, , (Throughput). Response Time, Throughput , : - .
2. Bandwidth, , .
3. VU, , , . .

ほとんどのグラフは、テスト後にHTMLベースのガトリングレポートを使用するか、Graphite-InfluxDB-Grafanaモニタリングバンドルを構成することで取得できます。表示には、ダッシュボードライブラリhttps://grafana.com/grafana/dashboards/9935の既製のダッシュボードを使用できます。



Gatlingのダッシュボードを分析およびコンパイルするときは、InfluxDBの結果が集約されて保存され、NT結果の予備評価にのみ適していることを考慮に入れる必要があります。テスト後、simulation.logをデータベースに再ロードし、それに関する最終レポートを作成して、システムパフォーマンスの問題を検索することをお勧めします。

メトリックのマトリックス記述

上記で説明したものはすべて、このすべての知識を要約した小さなタブレットの形で提示されます。