ロード テストで Web アプリケーションのブレークポイントを見つける方法

LoadViewプラットフォームを使用すると、Web アプリケーションの中断点を特定したり、パフォーマンスの低下が発生したり、アプリケーションが応答を停止したりする同時ユーザーの数を判断するのに役立つパフォーマンス テストを設定できます。 ストレス テストは、事前に決定されたレベルの同時ユーザーを使用して負荷のパフォーマンスを測定するロード テストとは異なり、Web アプリケーションのパフォーマンスが低下するまで、同時ユーザー数を徐々に増加させます。 Web アプリケーションのブレークポイントを見つけることは、次のような多くの理由から重要です。

• システム全体と環境がシステム障害と回復を管理する方法。
• 追加のハードウェア容量またはインフラストラクチャが必要かどうかを確認します。
• ディスク I/O、メモリ、CPU 使用率などのパフォーマンス メトリックを、他のサーバー メトリックと共に監視します。

ロード カーブ パターンと同時ユーザーの決定

負荷テストとストレス テストのロード カーブ パターンを決定することは、テストの精度の重要な側面です。 たとえば、最初から負荷が大きすぎて、アプリケーションがエラーで応答する場合、必ずしも低い負荷レベルが正常に処理できるとは限りません。 ロード テストでは、負荷は、ターゲット アプリケーションを訪問する同時ユーザーをシミュレートするロード インジェクタによって生成されます。 したがって、指定した同時ユーザー数で徐々に増加するロード パターンが適しています。 これにより、障害や劣化が発生するポイントを判断し、問題をより効率的に解決できます。

もう 1 つの要因は、テスト中にシミュレートする同時ユーザーの関連数を決定することです。 Google アナリティクスなどの Web 分析ツールは、現実的な開始負荷を計算する最も適切な方法ですが、最初に分析データがない場合は何をすべきでしょうか。 パフォーマンス テストの 同時ユーザーを決定する Web 分析の使用に関する 追加情報については、マイクロソフトのサポート技術情報の記事をお読みください。

ロードビュー: 荷重曲線の設定

LoadView プラットフォームでは複数のロードカーブから選択できますが、Web アプリケーションのブレークポイントを見つけようとすると、事前に定義された同時ユーザーまたはスループットでテストを実行する必要はありません。 これらの理由から、アプリケーションのブレークポイントを理解しようとする場合は、ゴールベースのカーブ荷重曲線よりも荷重曲線の優先的なオプションである荷重ステップカーブと動的調整可能曲線です。

ロード ステップ カーブを使用してロード テスト シナリオを設定する最も簡単な方法について説明します。

開始負荷の計算

ロード テストの初期負荷を計算するには、まず、使用している Web サーバーの数と使用可能な CPU コアの数を考慮します。 業界標準では、CPU コアあたり 25 人の同時ユーザーが 開始点にする必要がありますが、計算された開始点より 50% 低い数値から開始することをお勧めします。

開始点 = 25 x CPU コア数

推奨されるユーザー数 = (25 x CPU コア数) x 50%

たとえば、Web アプリケーションがクアッド コア Web サーバーで実行されていると仮定します。 開始する同時ユーザー数は、次のように計算されます。

開始点 = 25 x 4 CPU コア = 100 同時ユーザー

推奨されるユーザー数 = (25 x 4 CPU コア) x 50% = 50 同時ユーザー

テストを開始するユーザー数を指定するには、シナリオの開始ステップのフィールド を 使用します。

荷重曲線の設定

ランプアップ率

各ランプアップ ステップで 、開始点 の値の 25% ずつ負荷を上げることをお勧めします。

1 分あたりの負荷を上げるユーザー数を指定するには、 レイズ バイステップの対応するフィールドを使用します。

この例では、1 分間に 25 人のユーザーに相当するランプアップ率を示します。

テスト期間

テスト期間は、生成する最大負荷によって異なります。 アプリケーションのパフォーマンス要件に応じて、開始 点 の 5 ~ 10 倍の値に負荷を上げることをお勧めします。

• 負荷を 5 回上げる必要がある場合は、20 分を レイズバイ ステップの期間に設定します。
• 負荷を 10 回上げる必要がある場合は、40 分を レイズバイ ステップの期間に設定します。

この例では、40 分の期間でテストを実行し、仮想ユーザーの最大数は約 1,000 ユーザーになるようにしましょう。

ロード カーブが設定されたら、テストを開始し、テスト レポートで結果を確認します。 レポートには、テストの概要または概要が含まれ、テスト中の負荷レベルと応答時間の変化を示すグラフと折れ線グラフが含まれます。 レポート内のその他のセクションには、テスト セッションのログとデバイス情報が含まれます。

ロード テスト レポート の詳細と説明については、ロード テスト レポートのサポート技術情報を参照してください。

レポートを使用した Web アプリケーションのブレークポイントの決定

1 分間に 5 人の ユーザーの開始負荷を持つ基本的な HTTP ロード テストを考えてみましょう。 以下の図に、荷重曲線と対応するテスト結果を参照してください。

上記の例では、チャート上で応答時間と期間内のエラー数が黄色で表示され、大幅に増加しています。 要件に応じて、この期間中の任意のポイントを Web アプリケーションの「ブレークポイント」と考えることができます。

たとえば、エラー率が 0% を超える場合、アプリケーションにとって重要なエラーと見なされる場合、初めてエラーが発生したとき (またはサーバーが応答を停止した場合) は、Web アプリケーションのブレーク ポイントと見なすことができます。 または、応答時間が重要な場合、応答時間が事前に決定されたしきい値を超えたときにブレークポイントが発生します。

ロード テスト Web アプリケーション : ベスト プラクティス

負荷テストとストレス テストを成功に導く場合、計画と準備を行う必要はありません。 LoadView プラットフォームは、パフォーマンス エンジニアに必要なすべてのクラウド インフラストラクチャと負荷テスト機能を提供し、従来の複雑性や障壁を取り除くために役立ちます。 JMeter)。

実際のユーザー シナリオのスクリプト化

Web アプリケーションのテスト結果を成功させるためには、ユーザーとクライアントが Web アプリケーションを使用して移動する方法に合ったシナリオを作成することが、1 つの鍵となります。 一致する動作は、ロード テスト プロセスを開始する際に重要な要素です。 詳細については、EveryStep Web レコーダーをご覧ください。

実際のユーザーは予測できない場合があるため、ある程度の予測不能性とランダム性が必要となることに注意してください。 LoadView テストセットアップでは、ユーザー動作プロファイルから選択するか、カスタム構成を作成して、ユーザーの動作をより適切にシミュレートできます。 詳しくは、サポート技術情報の記事で ユーザー動作プロファイル の構成の詳細をご覧ください。

複数のリージョンからのテストの実行

最良の負荷とストレス テストの結果を確実に受け取る場合は、ユーザーが配置されている場所からテストする機能があります。 パブリック Web アプリケーションは、インターネット接続とブラウザを使用して、いつでも誰でも利用できます。 LoadView は、ロード テストとストレス テストを構成するために、20 を超えるグローバル クラウド (AWS および Azure) のネットワークロケーションを提供します。 テストは、ユーザーの大部分が Web アプリケーションにアクセスする地域または都市に一致するように構成する必要もあります。

ユーザーデバイスとネットワーク条件の照合

2G/3G/4G などの一般的なブラウザー、デバイス、ネットワーク接続など、ユーザーが配置されている場所に合わせてテストを設定および構成することで、テストをより微調整し、デバイス/ブラウザ レベルでのパフォーマンスに関するより良い洞察を得ることができます。 LoadViewプラットフォームは、40以上のデスクトップおよびモバイルブラウザ/デバイスをサポートしています。

パフォーマンスベースライン

Web アプリケーションが劣化を開始するポイントを見つける必要がありますが、最初に見つけ出すものではありません。 これまで Web アプリケーションでロード テストを実行したことがない場合は、ストレス テストに移行する前に、通常の日常のトラフィック レベルに一致するロード テスト シナリオを実行することをお勧めします。 通常の交通状況下での初期ロード テストでは、ピーク トラフィックの下でフルスケールのストレス テストを実行する前に、アプリケーションを強化する機会が見つからなくなることがあります。

LoadView: Web アプリケーションのブレークポイントを見つける

実際のブラウザ、EveryStep Web Recorder、地理分散型ロード インジェクタなどの機能を備えた LoadView は、パフォーマンス エンジニアだけでなく、実際のユーザー シナリオ用のテスト スクリプトを迅速に作成し、それらの Web アプリケーション スクリプトに対してロード テストやストレス テストを実行して世界中のパフォーマンスを理解する機能を備えています。