このトピックでは、パフォーマンス テストの実行に関する主要な技術要件について説明します。これらの技術要件は、パフォーマンス テスト サービス (PTS) ユーザーがシステムのオンライン化後に技術的なリスクを回避し、オンライン システムの実際の能力を評価し、ビジネス モデルに基づいてオンライン能力をテストして潜在的なリスクに事前に対処するのに役立ちます。
適用範囲
この技術要件は、パフォーマンス テストを必要とするすべてのプロジェクトに適用されます。この技術要件では、パフォーマンス テストの実行における重要かつ主要な技術について分析します。これには、システム環境、テスト指標、ビジネス モデル、データ量、テスト モデル、テスト タイプ、スクリプト (API)、シナリオ、監視、ボトルネック分析、チューニング、およびパフォーマンス テストで使用される分散クラウドベースのストレステスト ツールが含まれます。
システム環境
分析
システム環境は、本番環境、テスト環境、その他の環境に分類されます。本番環境とテスト環境には、それぞれ長所と短所があります。本番環境はより正確な測定とより最適化された参照を提供しますが、関連するすべてのテスト データをクリーンアップし、基本データの構造について後続のデータ量を参照するか、ビジネス インテリジェンス (BI) データの統計を収集する際に関連するテスト データをフィルタリングする必要があります。より効率的なソリューションは、Alibaba Cloud が提供するフルセッション ストレステストです。本番サービスへの悪影響を避けるため、稼働時間外に本番環境でストレステストを実行することをお勧めします。テスト環境のリスクを制御できます。ただし、テスト環境の構築には苦労し、テスト環境に対応する本番環境と同じ規模の構築には高いコストがかかります。したがって、一般的な解決策は、半分、4 分の 1、8 分の 1 などの比率に基づいてテスト環境を構築し、本番環境の一部のアプリケーションにテスト クラスタを個別にデプロイするか、データベースを共有することです。さらに、テスト環境では、過去 6 か月または 12 か月以内に生成されたデータなど、本番環境からマスクされた基本データをインポートして、データの関連性を維持する必要があります。これは、テスト環境で実行されるストレステストの精度と参照にとって重要です。
リスク
テスト環境のリスクは、主にテスト環境に対応する本番環境との違いにあります。したがって、テスト環境におけるテスト データの参照値は損なわれます。ニーズに対応する適切な方法を選択できます。たとえば、エントリのネットワークの検証を重視する場合は、テスト環境と本番環境でエントリを共有できます。テスト環境のオペレーティング システム プラットフォーム、ミドルウェア、およびデータベースに精通していない場合は、ボトルネックの分析とチューニングを簡単に行うことはできません。
要件
テスト環境の構築
前述の問題を理解したら、テスト環境の構築について次の要件を満たす必要があります。
テスト環境のアーキテクチャが、テスト環境に対応する本番環境のアーキテクチャと同じであることを確認します。
テスト環境のモデルが本番環境のモデルと同じであることを確認します。クラウドベースのリソースが同じ仕様の Elastic Compute Service (ECS) インスタンスまたはコンテナであることを確認します。
テスト環境のソフトウェア バージョンが本番環境のソフトウェア バージョンと同じであることを確認します。バージョンには、オペレーティング システム バージョン、ミドルウェア バージョン、データベース バージョン、およびアプリケーション バージョンが含まれます。
テスト環境のパラメータが本番環境のパラメータと同じであることを確認します。パラメータには、オペレーティング システム パラメータ、ミドルウェア パラメータ、データベース パラメータ、およびアプリケーション パラメータが含まれます。
テスト環境の基本データ量が本番環境の基本データ量と同じ桁数であることを確認します。
テスト環境のロード ジェネレータの数を減らし、テスト環境の他のリソースを比例的に縮小します。
テスト環境の理想的な構成は、本番環境の半分または 4 分の 1 であることに注意してください。
テスト環境の調査
テスト環境の次のレイヤーを調査する必要があります。
システム アーキテクチャ: システム構成、レイヤー機能、およびテスト環境に対応する本番環境との違いを調査できます。これらの結果は、主にボトルネック分析と本番環境のパフォーマンス評価に使用されます。
オペレーティング システム プラットフォーム: ツール監視を実行するために、オペレーティング システム プラットフォームを調査できます。
ミドルウェア: ツール監視とボトルネックの特定を実行するために、テスト環境のミドルウェアを調査できます。
データベース: ツール監視とボトルネックの特定を実行するために、テスト環境のデータベースを調査できます。
アプリケーション: 問題の発見とボトルネックの特定を実行するために、テスト環境で開始されるインスタンスとパラメータを調査できます。
Application Real-Time Monitoring Service (ARMS) などの Application Performance Management (APM) を使用して、ミドルウェア、データベース、またはアプリケーション レイヤーで発生する問題を特定できます。
テスト指標
分析
テスト指標は、ビジネス指標、リソース指標、アプリケーション指標、およびフロントエンド指標に分類されます。
ビジネス指標: 同時ユーザー数、1 秒あたりのトランザクション数 (TPS)、成功率、および応答時間 (RT) が含まれます。
リソース指標: CPU 使用率、メモリ使用率、I/O、およびセマフォとオープン ファイル数を含むカーネル パラメータが含まれます。
アプリケーション指標: アイドル スレッド数、データベース接続数、GC 数またはフル ヒープ GC 数、および関数の実行時間が含まれます。
フロントエンド指標: ページの読み込み時間と、ドメイン ネーム サービス (DNS) 解決時間、接続時間、および転送時間を含むネットワーク時間が含まれます。
リスク
ユーザーによって必要な指標の種類は異なり、期待も異なります。システム パフォーマンスをテストし、ボトルネックを特定し、パフォーマンスをチューニングするために、事前にさまざまな役割を持つさまざまな担当者に対して指標を調査し、指標固有のしきい値を指定する必要があります。事前にテスト指標に注意を払わないと、関係者が必要としない無効なテスト結果が得られる可能性があります。
要件
ビジネス指標
RT: この指標は、すべての関係者に共通です。事業部門は、この指標の具体的な値をより強く必要としています。ほとんどの場合、ビジネス RT の期待値はシステム サービスによって異なります。この指標は 1 秒以内の値に設定することをお勧めします。たとえば、淘宝網システム サービスの RT は基本的に数十ミリ秒以内です。
TPS: この指標は、システムが 1 秒あたりに処理するトランザクション数を示します。この指標は、システムの処理能力を測定する上で重要です。サービスの TPS を指定する際には、同じ ID のシステムとビジネスの TPS を参照できます。TPS は、中小企業で 50 ～ 1000、銀行で 1000 ～ 50000、淘宝網で 30000 ～ 300000 です。
成功率: この指標は、システムの負荷が高い場合の要求の成功率を測定します。ほとんどの場合、業界の成功率は 99.6% を超えています。
リソース指標
ほとんどの場合、システム リソース指標はボトルネック値を超えることはできません。たとえば、CPU 使用率を 75% に制限するか、システムがスワップ パーティションを使用しないようにする必要があります。理想的には、システムの能力が向上しない場合、リソースがボトルネックになります。これは、ほとんどの場合、他のボトルネックによって引き起こされるものではありません。この場合、リソースを追加すると、システムの能力も向上します。ただし、多くのシステム パフォーマンス テスト リソースがボトルネックに到達しない場合、ほとんどの場合、システムの能力は向上しません。
ビジネス モデル
分析
システムには多くのビジネスがあります。各ビジネス ロジックとビジネス量は同じではなく、各ビジネスで消費されるシステム リソースの量も異なります。したがって、ビジネスの種類とビジネスの比率によって、システムの処理能力が決まります。ビジネス モデルは、パフォーマンス テストにおいて重要な役割を果たします。たとえば、e コマースのシナリオでは、さまざまなプロモーション形式と主要カテゴリによって、さまざまなリソースの全体的な比率が決まります。したがって、ストレステストのために PTS に正確なトラフィックを着陸させ、システムのボトルネックを取得することで、マシン リソースを最大限に活用してビジネスの目的を達成できます。
リスク
ビジネス モデルに不適切なビジネスの種類とビジネスの比率が選択され、本番環境との違いが大きい場合、テスト結果は参照値を持ちません。さらに、システムの能力を誤解する可能性があります。一部のビジネスのビジネス量の比率はシステムでは非常に低いものの、変化はシステムにとって致命的です。したがって、パフォーマンス テストではビジネスに焦点を当てる必要があります。
要件
ほとんどの場合、使用頻度が高く、将来的に成長の可能性のある大量のリスクの高いビジネスをシステムの典型的なビジネスとして選択する必要があります。ピーク時の履歴ビジネス量と本番環境のパフォーマンスに基づいて、起動済みのシステムを評価できます。起動しようとしているシステムの場合は、調査結果とトランザクションのリソース消費に基づいてシステムを評価できます。
オンライン システム
本番環境でさまざまなピーク期間のビジネスの種類とビジネス量を収集し、各期間のビジネスの種類とビジネス量が大きく異なるかどうかを判断します。大きな違いがある場合は、複数のビジネス モデルを使用する必要があります。小さな違いがある場合は、1 つのビジネス モデルのみを使用できます。
本番環境でピーク時にリソース消費量が高く、リソース例外が発生する時点を収集し、リソース消費量が高く、リソース例外が発生する理由を把握します。
本番の問題を収集して分析します。問題がビジネスによって引き起こされ、以前のパフォーマンス テストでビジネスが無視されていた場合、ビジネスのリスクは非常に高く、後続のパフォーマンス テストでビジネス モデルに追加する必要があります。
オフライン システム
調査を実施して、ビジネスの種類とビジネスの比率を決定します。
調査を実施して、プロモーションやその他の活動で一部のビジネスが変化する可能性があるかどうかを判断します。
テスト結果に基づいて、各ビジネスのリソース消費量を決定します。比率の低い一部のビジネスが大量のリソースを消費する場合は、ビジネスの比率を調整する必要があります。
データ量
分析
データ量には、主に基本データ量 (履歴データ量、ボトム データ量、またはデータベース内の既存のデータ量) とパラメトリック データ量が含まれます。データ量は、パフォーマンス テストにおいて非常に重要な役割を果たします。数エントリのクエリ結果は、数百万エントリのクエリ結果と大きく異なります。ビジネス量が増加すると、エントリも増加します。したがって、テスト環境を使用する場合は、パフォーマンス テスト環境に対応する本番環境と同じ桁数のデータ量を維持する必要があります。本番環境にテスト アカウントを挿入する場合、環境の信頼性を確保し、基本データ量と同じ桁数をある程度維持できます。Alibaba Cloud が提供するフルセッション ストレステストでも、テスト環境と本番環境で同じ桁数の基本データ量が必要です。さらに、テスト中にパラメトリック データ量とデータ分布も考慮する必要があります。
リスク
テスト環境の基本データ量がテスト環境に対応する本番環境の基本データ量と同じ桁数でない場合、関連する指標の値は正しくありません。たとえば、応答時間は本番環境の応答時間よりもはるかに速く、テスト結果にも参照値がありません。パラメトリック データ量が小さすぎ、データ分布が考慮されていない場合、テスト結果は正しくなく、意味がありません。本番環境にテスト アカウントを挿入する場合は、データ準備の整合性とクリーンアップ ロジックを考慮する必要があります。Alibaba Cloud が提供するフルセッション ストレステストには、多額の変換コストが必要であり、継続的な反復とメンテナンスが必要です。
要件
基本データ量
テスト環境の基本データ量は、テスト環境に対応する本番環境の基本データ量と同じ桁数である必要があります。ほとんどの場合、今後 3 年間のデータ量の増加傾向を考慮する必要があります。データ量が急速に増加する場合は、テスト環境でより多くのデータを構築する必要があります。
パラメトリック データ量
パラメトリック データ量を最大化します。必要に応じて、キャッシュをクリーンアップするか、コードを記述してパラメトリック データ量を提供できます。
パラメトリック データを適切に配布します。ビジネスに明らかな地理的分布特性がある場合は、データ分布を考慮する必要があります。
テスト モデル
分析
テスト モデルは、ビジネス モデルから進化したものです。ほとんどの場合、テスト モデルとビジネス モデルは同じです。ただし、ビジネスのシミュレーションに失敗した場合、またはセキュリティ上の理由から、ビジネスを削除し、ビジネスの比率を再計算する必要があります。
リスク
前述のビジネス モデルのリスクを参照してください。
削除されたビジネスにリスクがある場合は、ビジネスのリスクを評価する必要があります。リスクが高い場合は、他のソリューションを採用する必要があります。
要件
前述のビジネス モデルの要件を参照してください。
テスト タイプ
分析
テスト タイプは、主に負荷テストとストレステストに分類されます。テスト タイプには、単一トランザクション ベンチマーク テスト、負荷テスト、ストレステスト、ハイブリッド トランザクション負荷テスト (容量テスト)、ビジネス変化テスト、ハイブリッド トランザクション安定性テスト、ハイブリッド トランザクション信頼性テスト、バッチ テスト、およびバッチ テストがハイブリッド トランザクションに及ぼす影響のテストが含まれます。各テスト タイプには異なる目的があります。本番システムの現実に基づいて適切なテスト タイプを選択できます。
リスク
テスト タイプがない場合、実際の本番システムの一部のシナリオが検出されず、システム クラッシュや RT の低下などのリスクが発生します。
要件
十分な時間がある場合は、ほとんどのテスト タイプをテストすることをお勧めします。次の要件も参照できます。
単一トランザクション ベンチマーク テスト: オプション。
単一トランザクション負荷テスト: オプション。システムがオフラインの場合は、システムの負荷テストを実行してリソース消費量を確認することをお勧めします。
ハイブリッド トランザクション負荷テスト (容量テスト): 必須。
ハイブリッド トランザクション ストレステスト: オプション。
ビジネス変化テスト: オプション。
ハイブリッド トランザクション安定性テスト: 必須。
ハイブリッド トランザクション信頼性テスト: オプション。
バッチ テスト: オプション。
バッチ テストがハイブリッド トランザクションに及ぼす影響のテスト: オプション。
ビジネス セッション
分析
ビジネス セッションは、ビジネスの意味を持つストレステスト API で構成される順序付けられたセットです。セッションはトランザクションに似ています。ビジネス セッションは、実行するビジネス操作をシミュレートするために使用されます。シミュレーションの修正は、システムのパフォーマンスに直接影響します。ビジネス操作をシミュレートするには、パラメータ化されたデータが必要です。パラメータ化されたデータの分布とデータ量の詳細については、「データ量」を参照してください。
リスク
ビジネスが成功しない場合、またはビジネス ロジックが実際の本番環境のビジネス ロジックと大きく異なる場合、テスト結果は参照値を持ちません。
要件
本番環境のビジネス ルールに基づいてビジネス セッションを調整します。
主要なポイントでサーバーの戻り値を確認し、チェックポイント (アサーション) をストレステスト API (ユーザーの動作によってトリガーされるクライアント上の要求) に追加します。詳細については、「インターフェース応答パラメータ」を参照してください。
データをパラメータ化し、データ量をできるだけ最大化します。
シナリオ
分析
(ストレステスト) シナリオは、複数の HTTP または HTTPS ベースの Uniform Resource Locator (URL) または API の組み合わせです。シナリオは、圧力モード、圧力増加方法、実行時間など、実際の本番環境のビジネス シナリオをシミュレートするために使用されます。シミュレートされたシナリオは、本番環境のシナリオと一致する必要があります。特に一定期間において、テストされた各ビジネスの TPS 比率は、本番環境のピーク時のビジネス比率と一致する必要があります。
リスク
シナリオのリスクは、テストされたビジネスの TPS 比率が本番環境のビジネス比率と一致しないことです。ビジネス比率がテストされた TPS 比率から大きく逸脱している場合、テスト結果は正しくなく、または無効であり、本番環境のビジネス シナリオを反映していません。
要件
テスト結果における各ビジネスの TPS 比率は、本番環境のビジネス モデルのビジネス比率と一致する必要があります。スループットをテストできる PTS 独自の 1 秒あたりの要求数 (RPS) モードを使用して、整合性を確保できます。たとえば、インターフェース A と B の比率が 1:4 で、RT がそれぞれ 1 ミリ秒と 100 ミリ秒の場合、PTS を使用してストレステストで 2 つのインターフェースの RPS を 1:4 の比率で設定するだけで済みます。従来の同時実行モードを使用する場合、比率が 1:400 になるように 2 つのインターフェースの同時実行を変換する必要があります。このようにして、最終的なビジネス モデルは本番環境のビジネス モデルと一致します。
監視
分析
監視は、主にパフォーマンス テスト分析を実行し、システムを包括的に監視し、ボトルネックをより効率的に特定するために設計されています。ほとんどの場合、オペレーティング システム、ミドルウェア、データベース、およびアプリケーションを監視する必要があります。各タイプの監視用に構成された指標がより包括的であることを確認します。
リスク
包括的なシステム監視がないと、パフォーマンス分析の実行、システム ボトルネックの特定、およびチューニング項目の識別に失敗します。
要件
次の指標に焦点を当てます。オペレーティング システム固有の指標: User、Sys、Wait、または Idle 指標で反映できる CPU 使用率、メモリ使用率 (スワップ パーティション使用率を含む)、ディスク I/O、ネットワーク I/O、およびカーネル パラメータ。
ミドルウェア固有の指標: スレッド プール、Java Database Connectivity (JDBC) 接続プール、および JVM (GC サイズ、フル ヒープ GC サイズ、またはヒープ サイズを含む)。
データベース固有の指標: 非効率的な SQL ステートメント、ロック、キャッシュ、セッション、およびプロセス数。
アプリケーション固有の指標: メソッドの実行時間、同期と非同期、バッファリング、およびキャッシュ。
ボトルネック分析
分析
ボトルネックの特定は、システムのボトルネック ポイントを分析し、チューニングの準備をするために設計されています。システムのパフォーマンス ボトルネック ポイントは、主にオペレーティング システム リソース、ミドルウェア パラメータ設定、データベースの問題、およびアプリケーション アルゴリズムに分散しています。的を絞ったチューニングは、システム パフォーマンスの向上に役立ちます。
リスク
システムのボトルネック ポイントを分析できない場合、新しいビジネス オンラインまたはコア ビジネスがリスクにさらされ、ピーク時にシステム パフォーマンスの低下やシステム クラッシュが発生する可能性があります。
要件
システム ボトルネック ポイントの分析には、次の指標に焦点を当てます。
オペレーティング システム リソース消費指標: CPU、メモリ、ディスク I/O、およびネットワーク I/O。
ミドルウェア指標: スレッド プール、JDBC 接続プール、および JVM (GC サイズ、フル ヒープ GC サイズ、またはヒープ サイズを含む)。
データベース指標: 非効率的な SQL ステートメント、ロック待機、デッドロック、キャッシュ ヒット率、セッション、およびプロセス。
アプリケーション: メソッドの実行時間、アルゴリズム、同期と非同期、キャッシュ、およびバッファリング。
ロード ジェネレータ: ロード ジェネレータのリソース消費量。ほとんどの場合、ロード ジェネレータがボトルネック ポイントになる可能性は低いです。PTS で使用されるロード ジェネレータには、個別に注意する必要のない保護とスケジューリング メカニズムがあります。
チューニング
分析
チューニングは、システム パフォーマンスを向上させるために設計されています。チューニングでは、システム ボトルネック ポイントを分析し、テストを通じてシステム パフォーマンスの向上を確認できます。
リスク
チューニングされていないシステムがオンラインになると、ユーザー エクスペリエンスが低下したり、システムがクラッシュしたりする可能性があります。
要件
システム チューニングは、次のルールに従います。
ミドルウェア チューニング: スレッド プール、データベース接続プール、JVM。
データベース チューニング: 非効率的な SQL ステートメント、デッドロックとロック待機、キャッシュ ヒット率、プロセス、およびセッション パラメータ。
アプリケーション チューニング: メソッドの実行時間、アルゴリズム、同期と非同期、キャッシュ、およびバッファリング。
システム リソース: ほとんどの場合、CPU などのシステム リソースの高消費は、リソースの不足ではなく、アプリケーションとパラメータの設定が不適切であることが原因です。
パフォーマンス テストで使用される分散クラウドベースのストレステスト ツール
概要
PTS は、強力な分散ストレステスト機能を提供し、大量のユーザーの実際のビジネス シナリオをシミュレートできる Web ベースのサービスとしてのソフトウェア (SaaS) パフォーマンス テスト プラットフォームです。
PTS は、世界中の数百都市とさまざまな事業者にデプロイされている Content Delivery Network (CDN) ノードからのアクセスをシミュレートできます。業界製品のクラウド ホストと比較して、PTS はより多くの地域でストレステストを迅速に開始し、より強力なパルスとトラフィック調整機能を提供します。PTS は、視覚的なページ オーケストレーションにより重点を置き、コーディングなしで複雑なインタラクティブ ストレステストを可能にし、RPS ストレステスト モードをサポートし、調整時にすぐに有効になる機能を提供します。
PTS は、パフォーマンス ストレステストの作業を継続的に簡素化して、ビジネスとパフォーマンスの問題に集中できるように設計されています。PTS を使用すると、実際のビジネス シナリオに最も近い複雑なインタラクティブ トラフィックを低労力と低リソース コストで構築し、システムのビジネス パフォーマンスの状態を迅速に測定し、パフォーマンスの問題の特定、容量比率設定の完了、フルセッション ストレステストのトラフィック構築の実行を容易にすることができます。これにより、ユーザー エクスペリエンスがさらに向上し、ビジネス開発が促進され、企業のビジネス価値が最大化されます。
機能
ストレステスト シナリオ構築
PTS は、順番にストレステストを実行するか、並列にストレステストを調整する API をサポートしています。データ ファイル、システム関数、文字列、および応答パラメータを含むパラメータ化された組み合わせを許可し、Cookie との高い互換性を提供し、幅広い命令拡張シナリオを提供します。PTS が提供するデバッグ機能を使用すると、複雑なシナリオのデータ フローを簡単に検証できます。
ストレステスト トラフィック調整
PTS は、同時実行モードと RPS モードをサポートしており、数分以内にストレステストを迅速に開始できます。PTS は偏差を減らし、自動モードと純粋な手動モードをサポートし、ストレステスト トラフィックの調整を数秒以内に有効にし、数千万のトラフィックの瞬間的なパルスを実装します。これにより、ストレッサー テスト トラフィックが時間内に停止します。
監視とストレステスト レポート
ストレステスト データには、同時実行、TPS、RT、および各 API のサンプリングされたログが含まれます。
メリット
安定性と信頼性
PTS は高い技術的安定性を提供します。
PTS は、e コマース、マルチメディア、金融と保険、物流 Express、広告とマーケティング、ソーシャル ネットワーキングなど、幅広い業界に適しています。
強力な機能
PTS は完全な SaaS 形式であり、追加のインストールとデプロイは不要です。
PTS は、主流のブラウザの記録プラグインをカバーしています。
PTS は、単純なエンコーディングを通じてストレステストで使用される API と URL の要求パラメータをフォーマットするデータ ファクトリとして機能します。
PTS は、複雑なシナリオを完全な視覚化方法で調整し、ログオン状態の共有、パラメータの受け渡し、およびビジネス アサーションをサポートし、多形式の思考時間とトラフィック調整をサポートする拡張可能な命令機能を提供します。
PTS は、RPS や同時実行など、複数のストレステスト モードをサポートしています。
PTS を使用すると、トラフィックを数秒以内に動的に調整し、1 秒あたり数百万回のクエリ (QPS) を即座に開始できます。
PTS は、ストレステスト クライアントのリアルタイム データを多次元で表示および統計する強力なレポート機能を提供し、イベント後の参照用にレポートを自動的に生成します。
PTS を使用すると、ストレステスト API とシナリオをデバッグし、ストレステスト プロセスのログをクエリできます。
実際のトラフィック
トラフィックは世界中の数百都市から来ており、すべての事業者をカバーしています。PTS は、エンド ユーザーのトラフィック ソースを真にシミュレートします。したがって、対応するレポートとデータは、実際のユーザー エクスペリエンスにより近くなります。
PTS は強力なストレス機能を提供し、高い RPS のストレステスト トラフィックをサポートします。