すべてのプロダクト
Search

このプロダクト

    Performance Testing:テスト分析とチューニング

    ドキュメントセンター

    Performance Testing:テスト分析とチューニング

    最終更新日:Jan 08, 2025

    テスト分析とチューニングは、パフォーマンステスト (PTS) の重要なステップです。このようにして、システムの期待されるパフォーマンスを確保できます。このトピックでは、開発者、テストエンジニア、および O&M エンジニアが迅速にパフォーマンステストを実行し、ボトルネックを特定し、チューニングを実施できるように、パフォーマンステストの分析とチューニングのプロセスと方法について説明します。システムのパフォーマンスは多くの要因によって決まります。このトピックではすべての要因について説明しているわけではありませんが、システムパフォーマンスを分析するためのガイドを提供できます。

    適用対象と範囲

    このトピックは、テスト分析とチューニングが必要な作業に適用されます。対象読者は、テスト管理者、テストオペレーター、テクニカルサポートエンジニア、プロジェクト品質管理者、プロジェクト管理者など、システムの技術的品質を保証する担当者です。

    パフォーマンス分析

    前提条件

    パフォーマンス分析を実行するには、PTS のクライアント監視、基本監視 (CloudMonitor)、Application Real-Time Monitoring Service (ARMS) 監視など、さまざまなパフォーマンステスト監視タスクを実行する必要があります。さらに、オペレーティングシステム、ミドルウェア、データベース、開発に関する知識など、関連する技術的知識を持っている必要があります。

    プロセス

    パフォーマンス分析は、システムのパフォーマンスボトルネックを特定して解決できる体系的なテストプロセスです。次の図は、パフォーマンス分析のプロセスを示しています。

    1. 多くの場合、ストレステストのトラフィックはバックエンド (サーバー側) に完全にルーティングされません。サーバーロードバランサー (SLB) インスタンス、Web アプリケーションファイアウォール (WAF) インスタンス、Anti-DDoS IP アドレス、コンテンツデリバリーネットワーク (CDN) アクセスポイント (POP)、またはエッジセキュリティアクセラレーション (ESA) POP などのクラウドベースのアーキテクチャを使用するネットワークアクセス層では、帯域幅、最大接続数、新規接続数などのさまざまな仕様の制限、または Challenge Collapsar (CC) や DDoS 攻撃に類似したストレステスト特性により、保護ポリシーがトリガーされる場合があります。これにより、予期しないテスト結果が生じます。詳細については、「バックエンドの負荷が小さい場合でもエラーまたはタイムアウトが発生するのはなぜですか？」をご参照ください。

    2. 主要なメトリックが要件を満たしているかどうかを確認する必要があります。主要なメトリックが要件を満たしていない場合は、問題の原因を特定する必要があります。ほとんどの場合、サーバー側が問題の原因である可能性が高く、クライアント側が問題の原因である可能性は非常に低いです。

    3. サーバー側で発生する問題については、CPU、メモリ、ディスク I/O、ネットワーク I/O などのハードウェアメトリックを確認する必要があります。ハードウェアメトリックが異常な場合は、詳細な分析を実行する必要があります。

    4. ハードウェアメトリックが正常な場合は、スレッドプール、接続プール、ガベージコレクション操作 (GC) などのミドルウェアメトリックを確認する必要があります。

    5. ミドルウェアメトリックが正常な場合は、低速な SQL クエリ、ヒット率、ロック、パラメーター設定などのデータベースメトリックを確認する必要があります。

    6. 上記のメトリックが正常な場合は、アプリケーションのアルゴリズム、バッファ、キャッシュ、同期 I/O、または非同期 I/O が異常である可能性があります。この場合は、詳細な分析を実行する必要があります。

    考えられるボトルネック

    システムの考えられるボトルネックを特定することは、テスト分析とチューニングの重要なステップです。リソースの不足や非効率的な方法などのパフォーマンスボトルネックは、システムの全体的なパフォーマンスを制限します。以下は、システムの一般的なパフォーマンスボトルネックです。

    • ハードウェアと仕様のボトルネック

      ほとんどの場合、ハードウェアと仕様のボトルネックには、CPU、メモリ、およびディスク I/O の問題が関係しています。

    • ミドルウェアのパフォーマンスボトルネック

      ほとんどの場合、ミドルウェアのパフォーマンスボトルネックには、データベースシステムと、アプリケーションサーバーや Web サーバーなどのアプリケーションソフトウェアが関係しています。たとえば、Weblogic プラットフォームで構成された Java Database Connectivity (JDBC) 接続プールの不適切なパラメーター設定は、パフォーマンスボトルネックを引き起こす可能性があります。

    • アプリケーションのパフォーマンスボトルネック

      ほとんどの場合、アプリケーションのパフォーマンスボトルネックには、開発者によって開発されたアプリケーションが関係しています。たとえば、多数のユーザーがシステムアプリケーションにアクセスするときにパフォーマンスボトルネックが発生する要因としては、不適切な Java 仮想マシン (JVM) パラメーターとコンテナー設定、Alibaba Cloud アプリケーションパフォーマンス監視 (APM) サービス (ARMS など) を使用して特定できる低速な SQL クエリ、不適切なデータベース設計とプログラムアーキテクチャ計画、シリアル処理、バッファリングとキャッシュの不足、リクエスト処理スレッドの不足、プロデューサーとコンシューマーの調整不足などの問題のあるプログラム設計などがあります。

    • オペレーティングシステムのパフォーマンスボトルネック

      ほとんどの場合、オペレーティングシステムのパフォーマンスボトルネックには、Windows、UNIX、および Linux オペレーティングシステムが関係しています。たとえば、パフォーマンステスト中に物理メモリが不足し、仮想メモリ設定が不適切な場合、仮想メモリの交換効率が大幅に低下し、動作応答時間が大幅に増加します。この場合、テスト中に使用されたオペレーティングシステムでパフォーマンスボトルネックが発生していると見なすことができます。

    • ネットワークデバイスのパフォーマンスボトルネック

      ほとんどの場合、ネットワークデバイスのパフォーマンスボトルネックには、ファイアウォール、動的ロードバランサー、スイッチが関係しています。クラウドベースのサービスアーキテクチャでよく使用されるネットワークアクセスサービスには、SLB インスタンス、WAF インスタンス、Anti-DDoS IP アドレス、CDN POP、ESA POP などがあります。たとえば、動的ロードバランサーには動的負荷分散メカニズムが構成されています。アプリケーションサーバーのハードウェアリソースが最大容量に達した場合、動的ロードバランサーは後続のトランザクションリクエストを負荷の低い他のアプリケーションサーバーに送信します。テスト中に、動的ロードバランサーがその役割を果たしていないことが判明しました。この場合、ネットワークボトルネックが発生していると見なすことができます。

    • 分析方法

      考えられるボトルネックの分析は、パフォーマンスボトルネックを特定し、システムのパフォーマンスに影響を与える制限を見つけることを目的としています。以下では、ボトルネックの一般的な分析方法をいくつか説明します。

      • CPU

        CPU 使用率が非常に高い場合は、CPU 消費状況を確認する必要があります。CPU 消費状況は、User、Sys、または Wait のいずれかになります。

        • CPU User 値が非常に高い場合は、大量の CPU リソースを消費しているプロセスを見つける必要があります。Linux アプリケーションを使用している場合は、top コマンドを実行して CPU 消費量を表示し、top -H -p <pid> コマンドを実行して CPU 使用率の高いスレッドを特定できます。Java アプリケーションを使用している場合は、jstack ツールを利用して、CPU 使用率の高いスレッドが実行しているスタックと CPU リソースを消費しているメソッドを表示できます。ソースコードを表示して、リソース消費量が多い理由を特定できます。C++ アプリケーションを使用している場合は、gprof パフォーマンツールを利用して分析を実行できます。

        • CPU Sys 値が非常に高い場合は、strace ツールを使用して、Linux アプリケーションでシステムの呼び出されたリソース消費量と時間を表示できます。

        • CPU Wait 値が非常に高い場合は、書き込むログの数を減らすか、非同期 I/O を実装するか、IOPS パフォーマンスの高いハードディスクに変更できます。CPU Wait 値が非常に高いのは、高頻度のディスク読み取り/書き込み操作が原因である可能性があります。

      • メモリ

        ほとんどの場合、オペレーティングシステムはメモリ使用率を最大化するために大きなキャッシュを提供します。したがって、メモリ使用率が 99% に達するのは正常です。メモリの問題を特定するには、プロセスが非常に大量のメモリを占有しているか、大量のスワップアクティビティを生成しているかを確認する必要があります。

      • ディスク I/O

        ディスク I/O の最も重要なメトリックの 1 つはビジー率です。これは、書き込むログの数を減らすか、非同期 I/O を実装するか、IOPS パフォーマンスの高いハードディスクを使用することで下げることができます。

      • ネットワーク I/O

        ネットワーク I/O は、主に送信されるコンテンツのサイズに依存し、ハードウェアの最大ネットワーク伝送の 70% を超えることはできません。コンテンツを圧縮することでコンテンツサイズを削減し、コンピューティングでキャッシュを構成するか、コンテンツを一括送信してネットワーク I/O パフォーマンスを向上させることができます。

      • カーネルパラメーター

        ほとんどの場合、カーネルパラメーターはデフォルト値を維持します。デフォルト値は、ほとんどのシステムで問題を引き起こしません。ただし、ストレステストで使用されるパラメーター値がデフォルト値を超え、システムの問題を引き起こす可能性があります。sysctl ツールを使用して、カーネルパラメーターを表示および変更できます。

      • JVM

        JVM は主に GC または FULL GC の頻度とガベージコレクション時間を分析します。これは、jstat コマンドを実行することで表示できます。各ヒープのサイズと、頻繁な GC に対処するには、jmap ツールを使用してメモリをダンプし、HeapAnalyzer ツールを利用して高いメモリ使用率を特定し、メモリリークが発生しているかどうかを判断できます。簡略化のために、Alibaba Cloud ARMS などの APM ツールを使用できます。

      • スレッドプール

        既存のスレッドが不十分な場合は、関連するパラメーターを調整してスレッドを追加できます。スレッドプールのスレッド設定が高くてもまだ不十分な場合は、詳細な分析を実行する必要があります。スレッド設定が高くても不十分な原因となる要因は次のとおりです。1. スレッドがブロックされ、タイムリーに解放できません。この場合、スレッドはロックを待機している可能性があります。2. 使用されるメソッドに時間がかかります。3. データベースの待機時間が長くなります。

      • JDBC 接続プール

        既存の接続プールが不十分な場合は、関連するパラメーターを調整して接続プールの数を増やすことができます。ただし、データベースの処理速度が遅い場合、調整はあまり効果がありません。データベースを表示し、コードで接続が解放されない理由を特定する必要があります。

      • SQL

        非効率的な SQL 実行も、パフォーマンス低下の非常に重要な理由です。現在の実行プランを表示して、SQL 実行が遅い理由を確認できます。ほとんどの場合、非効率的な SQL 実行の原因となる要因は次のとおりです。

        カテゴリ

        サブカテゴリ

        式または説明

        理由

        インデックス

        インデックスなし

        該当なし

        フルテーブルスキャンが実行されます。

        インデックス未使用

        substring(card_no,1,4)='5378'

        フルテーブルスキャンが実行されます。

        amount/30<1000

        フルテーブルスキャンが実行されます。

        convert(char(10),date,112)='19991201'

        フルテーブルスキャンが実行されます。

        where salary<>3000

        フルテーブルスキャンが実行されます。

        name like '%Tom'

        フルテーブルスキャンが実行されます。

        first_name + last_name ='beill cliton'

        フルテーブルスキャンが実行されます。

        id_no in('0','1')

        フルテーブルスキャンが実行されます。

        select id from t where num=@num

        パラメーターが存在する場合でも、フルテーブルスキャンが実行されます。

        パフォーマンスの低いインデックス

        非クラスター化インデックスを使用して oder by 操作を実行します。

        インデックスのパフォーマンスが低いです。

        username='Tom' and age>20

        文字列インデックスは、整数インデックスよりもクエリの効率が低くなります。

        値が NULL の列を含むテーブル。

        インデックスのパフォーマンスが低いです。

        IS NULL または IS NOT NULL の使用を控えます。

        インデックスのパフォーマンスが低いです。

        データ量

        合計データ量

        select *

        多くの列で大量のデータが生成されます。

        select id,name

        テーブルに数百万行が含まれており、大量のデータが生成されます。

        入れ子になったクエリ

        最初に元のデータを分析してから、データをフィルタリングします。

        大量の無駄なデータが生成されます。

        関連クエリ

        複数のテーブルに対して関連クエリを実行します。クエリでは、テーブルのデータのごく一部をフィルタリングしてから、データの大部分をフィルタリングします。

        多数の関連操作が実行されます。

        大量のデータが挿入されます。

        データは一度に挿入されます。

        大量のログが生成され、大量のリソースが消費されます。

        ロック

        ロック待機

        update account set banlance=100 where id=10

        行レベルのロックが生成され、テーブル全体がロックされます。

        デッドロック

        A:update a;update b;B:update b;update a;

        デッドロックが発生します。

        カーソル

        Cursor Open cursor,fetch;close cursor

        パフォーマンスが低いです。

        一時テーブル

        create tmp table ステートメントを実行して一時テーブルを作成します。

        大量のログが生成されます。

        DROP TABLE

        DROP TABLE ステートメントを実行して一時テーブルを削除します。

        システムは削除が成功したことを示す必要があり、これにより長時間のロックが防止されます。

        その他

        IN の代わりに EXISTS

        select num from a where num in(select num from b)

        IN はテーブルの各列を判断しますが、EXISTS はデータの行が返されるとすぐに実行中のクエリを終了します。

        select count(*) の代わりに EXISTS

        EXISTS はレコードが存在するかどうかを判断します。

        count(*) はテーブルの列数を累積的に計算しますが、EXISTS はデータの行が返されるとすぐに実行中のクエリを終了します。

        IN の代わりに BETWEEN

        ID in(1,2,3)

        IN はテーブルの各列を判断しますが、BETWEEN はフィールド値が指定された値の範囲内にあるかどうかを判断します。

        NOT IN の代わりに LEFT JOIN

        select ID from a where ID not in(select b.Mainid from b)

        NOT IN はテーブルの各列を判断します。したがって、NOT IN のクエリ効率は非常に低くなります。

        UNION の代わりに UNION ALL

        select ID from a union select id from b union

        UNION は重複行を削除し、ディスク上で結果をソートする場合がありますが、UNION ALL は結果をまとめてマージします。

        共通の SQL ステートメントへの変数のバインド

        insert into A(ID) values(1)

        SQL ステートメントを記述するたびにコンパイルが必要です。便宜上、共通の SQL ステートメントに変数をバインドできます。このようにして、ステートメントを一度だけコンパイルし、後で再利用できます。

    チューニング

    パフォーマンチューニングは、変化するアプリケーションと増加するユーザー負荷に合わせて継続的な監視と調整が必要な継続的なプロセスです。定期的なパフォーマンステストと分析は、問題をできるだけ早く特定し、各負荷条件下で安定したシステム動作を保証するのに役立ちます。チューニングは、コードの最適化、データベースの最適化、サーバーの構成、ネットワークの最適化など、多くの側面を網羅しています。

    プロセス

    1. 問題の特定

      • アプリケーションコード：通常、多くのプログラムのパフォーマンスの問題は、不適切なコードが原因です。したがって、ボトルネックのあるモジュールを特定し、最初にコードを確認します。

      • データベース設定：不適切なデータベース設定は、システム全体の動作を遅くする可能性があります。したがって、一部の大規模データベースでは、データベース管理者 (DBA) が適切なパラメーター調整を行ってからでないと、データベースを本番環境に導入できません。

      • オペレーティングシステム設定：不適切なオペレーティングシステム設定は、システムボトルネックを引き起こす可能性があります。

      • ハードウェア設定：ディスク I/O とメモリサイズは、ボトルネックを簡単に引き起こす可能性があります。

      • ネットワーク：ネットワークの過負荷は、ネットワークの競合とネットワークレイテンシを引き起こします。

    2. 問題の分析

      • 問題を特定したら、問題が応答時間またはスループットに影響を与えるか、または他の結果をもたらすかを明確にする必要があります。

      • ほとんどのユーザーが問題を経験しているか、それとも少数のユーザーだけが問題を経験しているか？問題を経験している少数のユーザーと他のユーザーの違いは何ですか？

      • システムリソースの監視データは正常ですか？ CPU 使用率は限界に達しましたか？ I/O はどうですか？

      • 問題は特定の種類のモジュールに集中していますか？

      • 問題はクライアント側ですか、それともサーバー側ですか？システムハードウェアの設定は十分ですか？

      • 実際の負荷はシステム負荷容量を超えていますか？システムを最適化する必要がありますか？

      上記の分析を実行し、他のシステムの問題を特定したら、システムボトルネックをより深く理解し、真の原因を特定できます。

    3. 調整目標とソリューションの特定

      システムスループットを向上させ、応答時間を短縮して、開発をより適切にサポートできます。

    4. ソリューションのテスト

      パフォーマンチューニングソリューションを適用するシステムでベンチマークテストを実行します。ベンチマークテストとは、科学的なテスト方法、テストツール、テストシステムを指定した後に、特定の種類のテスト対象のパフォーマンスメトリックを定量的かつ比較可能なテストのことです。

    5. チューニング結果の分析

      システムチューニングが期待される目標に到達または超過しているかどうか、システム全体のパフォーマンスが最適化されているか、またはシステムの一部のパフォーマンスが他の問題を解決するために最適化されているか、チューニング作業を完了できるかどうかを分析します。最終的に、期待される目標が達成されると、チューニング作業は終了します。

    注意事項

    • アプリケーションシステムの設計と開発では、常にパフォーマンスを考慮し、PTS を正規化し、定期的にイントラネットパフォーマンステストを実施し、定期的に実際の環境でビジネスパフォーマンステストを実施する必要があります。

    • 重要なのは、明確なパフォーマンス目標を特定することです。目標を特定したら、PTS のストレステストシナリオに目標を変換し、必要な負荷レベルを指定し、必要に応じて同時実行性、1 秒あたりのトランザクション数 (TPS) モード、自動インクリメントと手動調整の組み合わせを選択してトラフィック調整を行います。

    • 調整されたプログラムが期待どおりに実行されることを確認する必要があります。

    • システムパフォーマンスは、効果的な設計に大きく依存します。チューニングは補助的な手段にすぎません。

    • チューニングプロセスは、反復的で段階的なプロセスです。各チューニングの結果は、後続のコード開発にフィードバックされます。

    • パフォーマンチューニングでは、コードの可読性と保守性を犠牲にすることはできません。

    その他のテスト分析

    成功率

    成功率は、サーバー側によって返される値と構成されたアサーションに基づいて決定されます。アサーションが構成されていない場合、バックエンドサービスによって返されるエラーコード、サーバー例外、またはタイムアウトが原因でリクエストは失敗したと見なされます。

    ログ

    ログは各リクエストの情報を記録します。サンプリングレートが 10% の場合、100 件のリクエストごとに 10 件のリクエストに関する情報が記録されます。サンプリングレートが 100% の場合、各リクエストが記録されます。ただし、ロギングはロードジェネレーターの負荷を増加させ、パフォーマンスの低下とコストの増加につながります。ログサンプリングレートはサーバー側に影響しません。

    接続確立

    接続確立とは、Hypertext Transfer Protocol (HTTP) 接続を確立するプロセスのことです。指定された接続確立タイムアウト期間がリクエストによって超過された場合、リクエストはタイムアウトしたと見なされます。リクエストタイムアウト期間は、ドメインネームシステム (DNS) クエリから始まり、レスポンスコンテンツの受信で終了します。