Performance Testing:テストメトリックス

目的と対象読者

このトピックのメトリックスは、パフォーマンステストプロジェクトの技術的品質評価の基準として使用でき、技術的なテスト結果の評価を標準化し、技術的なテスト品質の測定を統一することができます。このトピックでは主要なメトリックスのみを扱っています。実際の技術的品質測定では、より多くのメトリックスが使用される場合があります。 対象読者には、テスト管理者、テストオペレーター、テクニカルサポート担当者、プロジェクト管理者、および技術品質関連担当者が含まれます。

システムパフォーマンスメトリックス

1. 応答時間

   1. 定義

      応答時間とは、クライアントがリクエストを開始してからサーバーから応答を受信するまでの時間です。パフォーマンステストでは、負荷が適用されてからテスト対象サーバーが結果を返すまでの期間が応答時間と見なされます。通常、秒またはミリ秒単位で測定されます。平均応答時間とは、システムが安定して動作しているときの同じトランザクションの平均値を指します。一般的に、トランザクションには平均応答時間が使用されます。 トランザクションの種類に応じて、平均応答時間は、複雑なトランザクション応答時間、単純なトランザクション応答時間、特別なトランザクション応答時間に大別できます。特別なトランザクション応答時間を設定する場合は、応答時間に関するトランザクションの特殊性を明確にする必要があります。

   2. 略語

      Response Time (RT)

   3. 基準

      許容される応答時間は、業界によって異なります。一般的に、オンラインリアルタイムトランザクションには次の値が適用されます。

      • インターネット企業：500ミリ秒未満。たとえば、淘宝網（タオバオ）の応答時間は 10 ミリ秒です。

      • 金融機関：1秒未満が望ましい、または複雑なトランザクションの場合は 3 秒未満。

      • 保険会社：3秒未満。

      • 製造会社：5秒未満。

      バッチ処理トランザクションの場合：

      • 時間枠：テストプロセス全体の期間。時間枠はデータ量によって異なります。たとえば、時間枠の値はダブル 11 と 99 プロモーションで異なります。大量のデータが関係する場合、テストは 2 時間以内に完了できます。

2. システム処理能力

   1. 定義

      システム処理能力とは、システムのハードウェアとソフトウェアを使用して情報を処理する能力を指します。 1 秒あたりにシステムが処理できるトランザクション数で測定されます。トランザクションは、オペレーターの観点からはビジネスプロセス、システムの観点からはビジネスアプリケーションと応答プロセスになります。前者はビジネストランザクションプロセスと呼ばれ、後者はトランザクションと呼ばれます。どちらのメトリックスもシステムの処理能力を評価できます。トランザクション統計を容易にするために、システムトランザクションログと一致するメトリックスを使用することをお勧めします。システム処理能力は、技術テスト活動における重要なメトリックスです。

   2. 略語

      一般的に、システム処理能力の測定には次のメトリックスを使用できます。

      • Hits per Second (HPS)：1 秒あたりのクリック数。

      • Transactions per Second (TPS)：システムが 1 秒あたりに処理するトランザクション数。

      • Queries per Second (QPS)：システムが 1 秒あたりに処理するクエリ数。 インターネットビジネスの場合、アプリケーションで 1 つのリクエスト接続のみが確立されている場合、TPS、QPS、および HPS は等しくなります。一般的に、TPS はビジネスプロセス全体を測定し、QPS は API クエリの数を測定し、HPS はサーバーに送信されたクリックリクエストを示します。

   3. 基準

      TPS、QPS、または HPS に関係なく、値が大きいほどシステム処理能力が高いことを示します。一般的に、次の値が許容されます。

      • 金融機関：1,000 TPS ～ 50,000 TPS（インターネットベースのアクティビティを除く）。

      • 保険会社：100 TPS ～ 100,000 TPS（インターネットベースのアクティビティを除く）。

      • 製造会社：10 TPS ～ 5,000 TPS。

      • E コマース企業：10,000 TPS ～ 1,000,000 TPS。

      • 中規模インターネット Web サイト：1,000 TPS ～ 50,000 TPS。

      • 小規模インターネット Web サイト：500 TPS ～ 10,000 TPS。

3. 同時ユーザー数

   1. 定義

      同時ユーザー数とは、指定された時点でシステムにログオンして操作を実行しているユーザーを指します。 持続接続を使用するシステムの場合、最大同時ユーザー数はシステムの同時実行能力を表します。短時間接続を使用するシステムの場合、最大同時ユーザー数はシステムの同時実行能力と等しくなく、システムアーキテクチャとシステム処理能力にも依存します。たとえば、システムが高いスループットを提供し、短時間接続を再利用できる場合、同時ユーザー数は多くの場合、システムの同時接続数よりも多くなります。TPS モード（または RPS モード）は、短時間接続を使用するほとんどのシステムに適しています。PTS は RPS モードでのテストをサポートしており、スループットテストの設定と測定を容易にします。 テストでは、仮想ユーザーを使用して現実世界のユーザーをシミュレートし、操作を実行します。

   2. 略語

      Virtual User (VU)

   3. 基準

      一般的に、パフォーマンステストは同時ユーザー数ではなく、システム処理能力を測定するために行われます。サーバーの長い接続が同時ユーザー数に影響を与える可能性があることを除いて、システム処理能力は同時ユーザー数とは無関係です。システム処理能力のテストでは、少数の同時ユーザーまたは多数の同時ユーザーを使用できます。

4. 失敗率

   1. 定義

      失敗率とは、システムに負荷がかかっているときにトランザクションが失敗する確率を指します。失敗率 =（失敗したトランザクション数/トランザクションの総数）× 100%。安定したシステムの場合、リクエストの失敗はタイムアウトによって発生するため、失敗率はタイムアウト率と等しくなります。

   2. 略語

      Failure Ratio (FR)

   3. 基準

      システムによって失敗率の要件は異なります。一般的に、6‰未満が許容されます。成功率は 99.4% 以上である必要があります。

リソースメトリックス

1. CPU

   1. 定義

      中央処理装置は非常に大規模な集積回路であり、コンピューターの計算コアおよび制御ユニットです。主にコンピューターの命令を解釈し、コンピューターソフトウェアのデータを処理するために使用されます。CPU 負荷は、システム内のリクエストキューの長さを測定し、システムの平均負荷です。

   2. 略語

      Central Processing Unit (CPU)

   3. 基準

      CPU 使用率は、主にユーザー、sys、wait、およびアイドルの 4 つのモードで CPU を測定するために使用されます。CPU 使用率のしきい値は 75% です。CPU sys% のしきい値は 30%、CPU wait% のしきい値は 5% です。シングルコア CPU でも上記の要件に準拠する必要があります。CPU 負荷は CPU コア数未満である必要があります。

2. メモリ

   1. 定義

      メモリはコンピューターの重要なコンポーネントの 1 つであり、CPU と通信するためのブリッジです。コンピューターのすべてのプログラムはメモリ内で実行されるため、メモリはコンピューターのパフォーマンスに大きな影響を与えます。

   2. 略語

      N/A

   3. 基準

      メモリ使用量を最大化するために、最新のオペレーティングシステムではメモリにキャッシュが追加されます。したがって、メモリ使用率が 100% であっても、必ずしもメモリボトルネックを意味するわけではありません。スワップ使用量は、多くの場合、メモリボトルネックを測定するために使用されます。一般的に、スワップ使用量は 70% 未満である必要があります。そうでない場合、システムパフォーマンスに影響を与える可能性があります。

3. ディスクスループット

   1. 定義

      ディスクスループットとは、ディスク障害なしに単位時間あたりにディスクを通過するデータ量です。

   2. 略語

      N/A

   3. 基準

      ディスクメトリックスには、IOPS、ディスクビジー率、ディスクキューの数、平均サービス時間、平均待ち時間、およびディスク使用率が含まれます。ディスクビジー率は、ディスクにボトルネックがあるかどうかを直接反映します。一般的に、ディスクビジー率は 70% 未満である必要があります。

4. ネットワークスループット

   1. 定義

      ネットワークスループットとは、ネットワーク障害なしに単位時間あたりにネットワークを通過するデータ量を指します。単位：バイト/秒。ネットワークスループットは、ネットワークデバイスまたはリンクの伝送容量に対するシステム要件を測定します。ネットワークデバイスまたはリンクの最大伝送容量に近づいた場合は、ネットワークデバイスをアップグレードする必要があります。

   2. 略語

      N/A

   3. 基準

      Mbps はネットワークスループットの主要なメトリックスです。一般的に、ネットワークデバイスまたはリンクの最大伝送容量の 70% を超えることはできません。

5. カーネルパラメーター

   オペレーティングシステムのカーネルパラメーターには、主にセマフォ、プロセス、およびファイルハンドルが含まれます。次の表に、これらのカーネルパラメーターを示します。

   レベル 1 メトリックス	レベル 2 メトリックス	単位	説明
   カーネルパラメーター	Maxuprc	N/A	ユーザーあたりの最大プロセス数。
   	Max_thread_proc	N/A	各プロセスで使用可能な最大スレッド数。
   	Filecache_max	バイト	キャッシュファイル I/O に使用可能な最大物理メモリ。
   	Ninode	N/A	HFS に使用可能なメモリ内の最大 inode 数。
   	Nkthread	N/A	同時に実行されている最大スレッド数。
   	Nproc	N/A	同時に実行されている最大プロセス数。
   	Nstrpty	N/A	ストリームに基づく疑似端末スレーブ（PTS）の最大数。
   	Maxdsiz	バイト	プロセスあたりの最大データサイズ（バイト単位）。
   	maxdsiz_64bit	バイト	プロセスあたりの最大データサイズ（バイト単位）。
   	maxfiles_lim	N/A	プロセスあたりのファイル記述子の最大数
   	maxssiz_64bit	バイト	プロセスあたりの最大スタックサイズ。
   	Maxtsiz	バイト	プロセスあたりの最大テキストサイズ。
   	nflocks	N/A	ファイルロックの最大数。
   	maxtsiz_64bit	バイト	プロセスあたりの最大テキストサイズ。
   	msgmni	N/A	システム v IPC メッセージキュー（ID）の最大数。
   	msgtql	N/A	システム v IPC メッセージの最大数。
   	npty	N/A	BSD 疑似 TTY（PTY）の最大数。
   	nstrtel	N/A	カーネルでサポートされている telnet デバイスファイルの数。
   	nswapdev	N/A	スワップデバイスの最大数。
   	nswapfs	N/A	スワップファイルシステムの最大数。
   	semmni	N/A	システム V IPC セマフォ ID の数。
   	semmns	N/A	システム V IPC セマフォの数。
   	shmmax	バイト	システム v 共有メモリの最大サイズ。
   	shmmni	N/A	システム v 共有メモリ ID の数。
   	shmseg	N/A	プロセスあたりのシステム v 共有メモリの最大サイズ。

ミドルウェアメトリックス

1. 定義

   ミドルウェアサービス（Tomcat や Weblogic など）の一般的なメトリックスには、JVM、ThreadPool、JDBC などがあります。次の表に、これらのメトリックスを示します。

   レベル 1 メトリックス	レベル 2 メトリックス	単位	説明
   GC	GC 頻度	N/A	Java 仮想マシンの部分ガベージコレクション頻度。
   	フル GC 頻度	N/A	Java 仮想マシンのフルガベージコレクション頻度。
   	平均フル GC 期間	秒	フルガベージコレクションの平均期間。
   	最大フル GC 期間	秒	フルガベージコレクションの最大期間。
   	ヒープ使用量	%	ヒープの使用量。
   スレッドプール	アクティブスレッド数	N/A	アクティブスレッドの数。
   	保留中のユーザーリクエスト	N/A	キューに入れられたユーザーリクエストの数。
   JDBC	JDBC アクティブ接続	N/A	JDBC アクティブ接続の数。

2. 基準

   • アクティブスレッド数は、指定された最大値を超えることはできません。一般的に、システムパフォーマンスが良好な場合は、最小値を 50、最大値を 200 に設定します。

   • JDBC アクティブ接続数は、指定された最大値を超えることはできません。一般的に、システムパフォーマンスが良好な場合は、最小値を 50、最大値を 200 に設定します。

   • GC 頻度、特にフル GC 頻度は、非常に高くすることはできません。一般的に、システムパフォーマンスが良好な場合は、最小 JVM ヒープサイズと最大 JVM ヒープサイズを 1024 M に設定します。

データベースメトリックス

1. 定義

   データベース（MySQL など）の一般的なメトリックスには、SQL、スループット、キャッシュヒット率、接続などがあります。次の表に、これらのメトリックスを示します。

   レベル 1 メトリックス	レベル 2 メトリックス	単位	説明
   SQL	期間	マイクロ秒	SQL ステートメントを実行するのにかかる時間。
   スループット	QPS	N/A	1 秒あたりのクエリ数。
   	TPS	N/A	1 秒あたりのトランザクション数。
   ヒット率	キーバッファヒット率	%	インデックスバッファのヒット率。
   	InnoDB バッファヒット率	%	InnoDB バッファのヒット率。
   	クエリキャッシュヒット率	%	クエリキャッシュのヒット率。
   	テーブルキャッシュヒット率	%	テーブルキャッシュのヒット率。
   	スレッドキャッシュヒット率	%	スレッドキャッシュのヒット率。
   ロック	待機	N/A	ロック待機の回数。
   	待ち時間	マイクロ秒	ロック待ち時間。

2. 基準

   • SQL 期間は短い方が望ましいです。一般的に、マイクロ秒単位です。

   • ヒット率は高い方が望ましいです。一般的に、95% 未満にすることはできません。

   • ロック待機の回数とロック待ち時間は小さい方が望ましいです。

フロントエンドメトリックス

1. 定義

   一般的なフロントエンドメトリックスには、ページ表示時間とネットワーク表示時間が含まれます。次の表に、これらのメトリックスを示します。

   レベル 1 メトリックス	レベル 2 メトリックス	単位	説明
   ページ表示	最初のコンテンツの描画	ミリ秒	アドレスバーに URL を入力してから、Web ページに最初のコンテンツが表示されるまでの時間。
   	OnLoad イベント時間	ミリ秒	ブラウザが onLoad イベントをトリガーするまでの時間。このイベントは、元のドキュメントと参照されているすべてのコンテンツが完全にダウンロードされたときにトリガーされます。
   	完全にロードされるまでの時間	ミリ秒	すべての onLoad JavaScript プログラムを完了し、それらのプログラムによってすべての動的または遅延ロードコンテンツをトリガーするまでの時間。
   ページ	ページサイズ	KB	ページ全体のサイズ。
   	リクエスト	N/A	Web サイトからリソースをダウンロードするときのすべてのネットワークリクエストの総数。小さい値が望ましいです。
   ネットワーク	DNS 時間	ミリ秒	DNS ルックアップ時間。
   	接続時間	ミリ秒	ブラウザと Web サーバー間で TCP/IP 接続を確立するまでの時間。
   	サーバー時間	ミリ秒	サーバーによる処理時間。
   	転送時間	ミリ秒	コンテンツを転送するまでの時間。
   	待ち時間	ミリ秒	リソースが解放されるのを待つ時間。

2. 基準

   • ページサイズは小さい方が望ましく、圧縮を使用できます。

   • ページ表示時間は短い方が望ましいです。

安定性メトリックス

1. 定義

   最小安定時間：最大容量または標準負荷（予想される日次負荷）の 80% の条件下でシステムが安定して動作できる最小時間。 一般的に、営業日（8 時間）に稼働するシステムの場合、少なくとも 8 時間安定して動作する必要があります。24 時間 365 日稼働するシステムの場合、少なくとも 24 時間安定して動作する必要があります。 システムが安定して動作できない場合、ビジネスワークロードと実行時間の増加に伴い、パフォーマンスの低下やクラッシュが発生する可能性があります。

2. 基準

   • TPS 曲線は大規模な変動なしにフラットなままです。

   • リソースメトリックスでは、リークや例外は発生しません。

バッチ処理メトリックス

1. 定義

   バッチ処理プログラムが単位時間あたりに処理するデータ量。一般的に、1 秒あたりに処理されるデータ量で測定されます。処理効率は、バッチ処理時間枠を推定するための最も重要なメトリックスです。 異なるシステムのバッチ処理時間枠の開始時刻と終了時刻は重複する場合があります。システムには同時に実行される複数のバッチプロセスがあり、それらの時間枠は重複する可能性があります。 長期間のバッチ処理タスクは、オンラインリアルタイム取引のパフォーマンスに影響を与えます。

2. 基準

   • 大量のデータが関係する場合は、バッチ処理時間枠は短い方が望ましいです。

   • オンラインリアルタイム取引のパフォーマンスに影響を与えることはできません。

スケーラビリティメトリックス

1. 定義

   アプリケーションプログラムまたはオペレーティングシステムがクラスターモードでデプロイされている場合のハードウェアリソースの増加とパフォーマンスの増加の比率。式：（パフォーマンスの増加/元のパフォーマンス）/（リソースの増加/元の資源）× 100%。 スケーラビリティメトリックスの傾向は、複数回のテスト後に取得できます。 アプリケーションシステムのスケーラビリティが高い場合、そのスケーラビリティメトリックス値は線形またはほぼ線形である必要があります。大規模分散システムは、多くの場合、高いスケーラビリティを備えています。

2. 基準

   • 理想的なケースでは、リソースの増加とパフォーマンスの増加は線形関係にあります。

   • パフォーマンスの増加は 70% 以上である必要があります。

信頼性メトリックス

1. ホットスタンバイデプロイメント

   ホットスタンバイデプロイメントは、高可用性を確保するために使用されます。信頼性を測定するには、次のメトリックスを使用できます。

   • ノードの切り替えが成功したかどうか、および実際に消費された時間。

   • ノードの切り替え中にビジネスが中断されたかどうか。

   • ノードのスイッチバックが成功したかどうか、および実際に消費された時間。

   • ノードのスイッチバック中にビジネスが中断されたかどうか。

   • ノードのスイッチバック中に失われたデータ量。ホットスタンバイテストでは、負荷生成ツールを使用してシステムにパフォーマンス負荷を適用し、テスト結果が実際の運用条件と一致するようにすることができます。

2. クラスターアーキテクチャ

   クラスターアーキテクチャを使用するシステムのクラスターの信頼性を測定するには、次のメトリックスを使用できます。

   • クラスター内のノードに障害が発生した場合にビジネスが中断されたかどうか。

   • クラスターに新しいノードを追加するときにシステムを再起動する必要があるかどうか。

   • 障害が発生したノードが復旧してからクラスターに追加されるときにシステムを再起動する必要があるかどうか。

   • 障害が発生したノードが復旧してからクラスターに追加されるときにビジネスが中断されたかどうか。

   • ノードの切り替えにかかる時間。クラスターの信頼性テストでは、負荷生成ツールを使用してシステムにパフォーマンス負荷を適用し、テスト結果が実際の運用条件と一致するようにすることができます。

3. バックアップと復元

   この項目では、システムのバックアップと復元メカニズムが効果的で信頼できるかどうかを確認します。これには、システムのバックアップと復元、データベースのバックアップと復元、アプリケーションのバックアップと復元が含まれます。バックアップと復元の信頼性を測定するには、次のメトリックスを使用できます。

   • バックアップが成功したかどうか、および実際に消費された時間。

   • スクリプトを使用してバックアップが自動化されているかどうか。

   • 復元が成功したかどうか、および実際に消費された時間。

   • スクリプトを使用して復元が自動化されているかどうか。

   • メトリックスの選択と検証は、システムのテスト目的とテスト要件によって異なります。システム、テスト目的、またはテスト要件が異なれば、異なるメトリックスを使用できます。

   • 一部のシステムで追加のフロントエンドユーザーアクセス機能が必要な場合は、ユーザーアクセス同時実行メトリックスを追加する必要があります。

   • バッチ処理パフォーマンスを確認するには、バッチ処理効率とバッチ処理時間枠を使用します。

   • システムパフォーマンス容量を確認するには、メトリックス定義に基づいてテスト要件でメトリックス要件を指定する必要があります。

   • テストメトリックスを取得したら、関連する前提条件（ワークロードやシステムリソースなど）を指定する必要があります。