[2023 インターネット上で最も Diao チュートリアル] パフォーマンス テスト学習ノート (超詳細~)

目次

性能試験

コンセプト

パフォーマンス

モデル

パフォーマンステスト計画

パフォーマンス監視

パフォーマンステストには事前に設定された条件が必要です

パフォーマンステストにはシナリオが必要です

パフォーマンステストの分析と調整

TPSとレスポンス（RT）の関係は何ですか？

パフォーマンス

パフォーマンス分析のアイデア

パフォーマンスシナリオの設計

パフォーマンス監視の設計

オペレーティング システムでよく使用されるカウンタ

終了 学習リソースの共有のサポート

性能試験

コンセプト

• パフォーマンステストは、システムのパフォーマンス指標を目的としており、パフォーマンステストモデルの確立、パフォーマンステスト計画の開発、監視戦略の策定、シナリオ条件下でのパフォーマンスシナリオの実行、パフォーマンスのボトルネックの分析と判断、最適化を行い、最終的に評価するためのパフォーマンス結果を取得します。システム性能指標 所定の値を満たしているかどうか。

パフォーマンス

• メトリクスには、時間メトリクス、容量メトリクス、リソース使用率メト​​リクスが含まれます。
  • 時間インデックスは、インターフェイスの応答時間、ビジネスの応答時間を指します。
  • 容量インジケーターは、インターフェイス容量、サービス容量を指します。
  • リソース使用率インジケーターは、オペレーティング システム (CPU、IO、メモリ、ディスク、ネットワーク、システム)、JVM などを指します。
• 指標の由来: ビジネスシナリオに応じてチームメンバーとのディスカッションによって取得される場合もあれば、実際のストレステストでは指標が設定されず、システムのパフォーマンスボトルネックを確認することが目的である場合もあります

モデル

• モデルは実際のシーンの抽象化を指し、ビジネス モデルがどのようなものであるかをパフォーマンス テスターに​​伝えることができます。
• 平たく言えば、このモデルはテスターに​​特定のビジネスの同時実行性を知らせることができ、テスターはモデルに従って特定の圧力比を設計するのに便利です。
• モデルデータの取得：通常、本番環境の統計情報から取得（各ノードのログを取得し、ログからトラフィック状況を分析するなど）

パフォーマンステスト計画

• 計画に含まれる内容：テスト環境、テストデータ、テストモデル、パフォーマンスモデル、プレッシャー戦略、エントリーとイグジット、スケジュールリスク

パフォーマンス監視

• レイヤ化とセグメンテーションの機能に加え、グローバル監視と指向性監視の機能が必要です。

パフォーマンステストには事前に設定された条件が必要です

• ここでの条件には、ハードウェアおよびソフトウェア環境、テストデータ、テスト実行戦略、圧力補正などが含まれます。

パフォーマンステストにはシナリオが必要です

• 確立された環境（動的拡張などの戦略を含む）、確立されたデータ（シナリオ実行時のデータ変更を含む）、確立された実行戦略、および確立された監視の下でパフォーマンス スクリプトを実行し、システムのすべてのレベルでパフォーマンス ステータス パラメータの変化を監視します。分析シナリオが期待どおりかどうかをリアルタイムで判断
• シナリオ分類: ベンチマーク性能テスト、容量性能シナリオ、安定性性能シナリオ、異常性能シナリオ

パフォーマンステストの分析と調整

• 性能項目の分類
  • 新しいシステム パフォーマンス テスト クラス: このようなプロジェクトでは通常、システムの最大容量をテストする必要があります。
  • 旧システム新バージョン性能テストカテゴリ：このようなプロジェクトは一般に旧バージョンと比較され、性能が低下しない限り過去のデータに基づいて容量を計算でき、チューニングの要件も大きくありません。
  • 新しいシステム パフォーマンス テスト最適化クラス: このタイプのシステムは、最大容量をテストするだけでなく、最適な状態に調整する必要があります。

パフォーマンステストには結果レポートが必要です

• 内容：チューニング前後のTPS、応答時間、リソース比較表

TPSとレスポンス（RT）の関係は何ですか？

• 実際のパフォーマンステストでは、同時接続ユーザー数が勾配によって増加すると仮定すると、最初は TPS がゆっくりと上昇し、このときの RT はしばらく低いレベルに留まり、圧力が継続することになります。増加すると、TPS も上昇します。RT もゆっくりと上昇します。TPS が限界に達し、圧力が増加し続けると、RT は急速に上昇し、最終的にタイムアウトに達します。

パフォーマンス

需要インジケーター

• 経営指標
  • ビジネス レベルの指標。ビジネス側が 1,000 万人のオンライン ユーザーを必要とする場合、引き続き n 個のパフォーマンス シナリオに分割でき、各パフォーマンス シナリオには対応する固定値のビジネス比率もあります。
• テクニカル指標
  • RT 応答時間 (応答時間) は一般に応答時間と呼ばれ、要求時間と応答時間が含まれます。
  • 1 秒あたりの HPS ヒット数 (1 秒あたりのヒット数)
  • 1 秒あたりの TPS トランザクション数
  • QPS は、mysql の 1 秒あたりの SQL 数を指します。
  • 1 秒あたりの RPS リクエスト
  • 1 秒あたりの CPS HTTP リターン コード
  • PVページビュー数
  • UV ユニークビジター
  • IPに依存しないIP番号
  • スループット スループット
  • IOPS は通常ディスクを表します

パフォーマンス指標の概念

• TPS

  • TPS の粒度はシナリオに従って定義する必要があります。インターフェイス層のパフォーマンス テストの場合、T はインターフェイス レベルです。ビジネス レベルのパフォーマンス テストの場合、T は各ビジネス ステップと完全なビジネスとして直接定義できます。フロー。

• 同時ユーザー

  • 絶対同時実行数: 同時実行の数
  • 相対同時実行数: 一定期間内の同時実行数
  • TPS を使用して同時実行の概念を実行する

• オンライン ユーザーと同時ユーザーの数

  • オンライン ユーザーの数は、一定期間内のシステム上のユーザーを指し、これらのユーザーが必ずしもアクションを実行するとは限りません。
  • 規定同時ユーザー数とは、一定期間内に上記オンラインユーザーが一定のサービス上でアクションを行ったユーザー数です（同時ユーザー数＝オンラインユーザー数×同時度）

• 公式

  

パフォーマンス分析のアイデア

• 一般的なアイデア
  • ボトルネックを正確に判断
  • スレッド増加の戦略
  • パフォーマンス低下のプロセス
  • 応答時間の分割
  • 構築分析デシジョン ツリー
  • シーンの比較
• ボトルネックを正確に判断
  • TPS曲線

    

  • スレッドが同じ割合で増加すると仮定すると、上の図では、理論的には 2 番目のステップの TPS は最初のステップの 2 倍になるはずであるため、パフォーマンスのボトルネックがすでに 2 番目のステップで発生していることがわかりますが、つまり、パフォーマンスのボトルネックが存在します
  • TPSの意味（TPSカーブから得られる情報）
    • ボトルネックはありますか: 実際、すべてのシステムにパフォーマンスのボトルネックがあると言っても過言ではありません。それは、パフォーマンス テストをどの程度の大きさで行うかによって異なります。
    • ボトルネックと圧力の間には関係がありますか: TPS は圧力によって変化するため、関係があります。圧力が増加するかどうかに関係なく、TPS には曲線トレンドの問題が発生しますが、これは無関係です。
  • 応答時間曲線
    • TPS曲線と応答時間曲線のポイント
      • 応答時間はビジネスの速さを判断するために使用され、TPS はキャパシティを判断するために使用されます。
• スレッド増加の戦略
  • 2 つのスレッド増加シナリオ

    

  • 要約する
    • システムの場合、圧力戦略のみが変更された場合 (環境、データ、ソフトウェアおよびハードウェア構成などの他の条件は変更されないまま)、システムの最大 TPS 上限は固定されます。
    • セクスキルシナリオのテストに関しては、初期段階でウォームアップを行う必要があり、予熱とは、ある程度の交通量で走行した後、急激に圧力を上げることを指し、直接入力するのではなく、より実際の現場に近いものとなります。一度に大量のトラフィックが発生するシステム。
• パフォーマンス低下のプロセス
  • スレッドごとの 1 秒あたりの TPS が減少し始めると、パフォーマンスのボトルネックが発生したことを意味します。ただし、ボトルネックが発生した後もサーバーの処理能力（ここではTPSで説明します）が低下するわけではなく、TPSは上昇する一方、継続的な性能低下の過程でTPSは低下していきます。上限に達します。
• 応答時間の分割

  

• 構築分析デシジョン ツリー
  • 構造を整理し、システムを整理し、問題を整理し、証拠連鎖を見つけるプロセスを整理し、分析のアイデアを整理します。全体を俯瞰し、上を見据える先導的な役割を果たします。
• シーンの比較
  • システム内のリンクが機能していないと感じ、それを分析する能力がない場合は、リンクを直接増やすことができます。

パラメトリックデータ

• パラメトリックロジック
  • ビジネスシナリオを分析する
  • パラメータ化する必要があるデータと対応する関係をリストします。
  • パラメータ化されたデータをデータベースから取得するか、対応する生成ルールを設計します
  • パラメトリック データを別のファイルに合理的に保存する
  • 実際のシーンをシミュレートするために、圧力ツールで対応するパラメーターの組み合わせ関係を設定します。

パフォーマンス シナリオ: パラメータ化を行う前に考慮すべきこと

• 注意が必要なデータ
  • パラメータ化されたデータ、モニタリングデータ、および基本的な敷設データ

パラメトリックデータ

• パラメータ化されたデータで考えられる状況
  • データの不均衡
  • パラメータ化されたデータの量が不十分です

パラメトリックデータに関する質問

• パラメトリック データにはどのくらいのデータを使用する必要がありますか?

  

• パラメトリック データはどこから来たのでしょうか?

  • パラメトリックデータは主に 2 つのカテゴリに分類されます
    • ユーザーが入力したデータは、上記の例のユーザー データなど、バックグラウンド データベースにすでに存在します。
      • データの特性: バックグラウンド データベースに保存され、ユーザー入力が必要です。ユーザーが入力したデータはバックグラウンド データベースのデータと比較されます。
      • このようなデータは、ツールにパラメータ化する前にデータベースにクエリを実行する必要があります。
    • ユーザーが入力したデータはバックエンド データベースに存在しません。ビジネス フローでは、これらのデータはデータベースに挿入または更新されます。
      • データ特性: これらのデータは元々データベースに存在しません。これらのデータは、スクリプトが正常に実行された後にデータベースに挿入または更新されます。ビジネス特性に応じて、各ユーザーが入力したデータは同じである場合もあれば、異なる場合もあります。
      • このようなデータは圧力ツールによってパラメータ化する必要があり、ビジネス ルールも満たさなければなりません。
        • データ満足条件: 運用環境でのデータの分散を満たすこと、パフォーマンス シナリオでのデータ量要件を満たすこと。

• 多かれ少なかれパラメータの選択はシステム圧力にどのような影響を与えますか?

  • 取得したパラメータが多すぎるとシステムへの負荷が大きくなり、取得したパラメータが少なすぎると実際のシーンのデータ量に適合せず、システムの実際の負荷をテストできなくなります。

• パラメトリック データのヒストグラムはデータベース内でバランスが取れていますか?

  • 各ユーザーのデータ分布がビジネスシナリオに適合しているかどうかを指し、例えば同じ受注業務において、ユーザーAには数十万のデータを作成し、ユーザーBには数個のデータを作成するのは明らかに無理があります。

パフォーマンスシナリオの設計

予備作業

• テストが必要な業務とその業務の該当業務割合を確認（ログから取得可能）
• ビジネス目標TPSの決定
• ビジネス目標の応答時間を決定する

ベースライン パフォーマンス シナリオ

• 目的
  • 単一サービスの最大容量をテストするため、混合容量シナリオでどのサービスが全体の容量に最も大きな影響を与えるかを判断するため。

容量とパフォーマンスのシナリオ

• 主なポイント
  • 常にシーン
  • 制御率
• 容量TPSの計算方法
  • 各ビジネスのTPSを合計するだけです

安定性パフォーマンスのシナリオ

• 主なポイント
  • 安定性は通常、システムが一定期間安定して実行されることを強調します。たとえば、1 週間オンラインで安全に実行するには 2,000 万のビジネス ボリュームが必要です。
  • 最小テスト期間 = 2000w / 容量 TPS (この値は容量およびパフォーマンス シナリオの計算方法によって異なります)

異常なパフォーマンスのシナリオ

• 試験方法
  • 一般的には、さまざまなサービスを不安定にするためです。たとえば、メインの Redis がダウンし、Redis の切り替えによって機能上の問題が発生するかどうかを確認します。

パフォーマンス監視の設計

設計ステップのモニタリング

• システムのアーキテクチャを分析し、個々のコンポーネントを監視します
• モニタリングにはレベルとステップが必要です。まず全体的な状況を把握し、次に対象を絞った定量分析を行います。
• 全体的、方向的、階層的な監視データを分析し、分析結果に基づいて次に収集する情報を決定し、完全な証拠の連鎖を見つけます。

グローバル監視設計

os层

• パラメータに注目: CPU、I/O、メモリ、ネットワーク、システム、スワップ

CPUパラメータ	パラメータの意味
アイドル状態	CPU がアイドル状態である時間の割合
アイオウェイト	I/Oの待機に費やされたCPU時間の割合
IRP	邪魔をして
良い	通常のプロセスの実行に費やされた CPU 時間の割合
ソフトリップ	ソフト割り込み
窃盗
システム	システムプロセスによって消費された CPU 時間の割合
ユーザー	ユーザープロセスによって消費された CPU 時間の割合
CPUキュー

IO/ディスクパラメータ	パラメータの意味
TPS	物理デバイスへの 1 秒あたりの合計 I/O 転送数
rqm/秒	1 秒あたりにマージされた読み取り操作の数
wrqm/秒	1 秒あたりにマージされた書き込み操作の数
r/s	1 秒あたりに完了した読み取り I/O デバイスの数
付き	1 秒あたりに完了した書き込み I/O デバイスの数
バイ	ブロックデバイス、つまり読み取りディスクによって読み取られたデータの総量
ボー	ブロックデバイスに書き込まれた、つまりディスクに書き込まれたデータの総量
r_await	読み取りの平均応答時間を示します。
w_待ってます	書き込み平均応答時間

メモリパラメータ	パラメータの意味
合計	物理メモリの合計サイズ
無料	利用可能なメモリ (利用可能なメモリを参照)
使用済み	使用済みメモリ
バフ/キャッシュ	合計バッファメモリ
利用可能	実際に使用可能なメモリ

ネットワークパラメータ	パラメータの意味
TX: トラフィックを送信する
RX: トラフィックを受信します
送信Q/受信Q	送信キュー、受信キュー
接続キューがいっぱいです
セミジョインキュー

システムパラメータ	パラメータの意味
割り込み	特定の時間間隔で観察された 1 秒あたりのデバイス割り込みの数を示します。
コンテキストスイッチ	1秒あたりに生成されるコンテキストスイッチの数

スワップ	パラメータの意味
合計	総交換エリア
無料
使用済み
と	メモリスワップ領域に入るメモリのメモリサイズ
それで	メモリに入るメモリスワップ領域のメモリサイズ

ミドルウェア

• メッセージキュー

  • 指標には、生産速度と消費速度が含まれます。
  • rabittmq にメッセージの蓄積があると仮定すると、解決策は
    • 消費者を増やす（消費のスピードが生産のスピードに追いつかないため）
    • 若增加消费者也不能解决，那么有可能是服务端出bug了，导致无法消费

• redis

  

• mysql

  

操作系统常用计数器

• 命令模块

  

• CPU参数含义
  • us CPU 是用户态进程消耗的 CPU 百分比
  • wa cpu是 I/O 读写等待消耗的 CPU 百分比。
  • sy CPU 是内核消耗的 CPU 百分比
  • si CPU 是软中断消耗的 CPU 百分比

---

如果文章对你有帮助，记得点赞，收藏，加关注。会不定期分享一些干货哦......

END配套学习资源分享

最后： 为了回馈铁杆粉丝们，我给大家整理了完整的软件测试视频学习教程，朋友们如果需要可以自行免费领取 【保证100%免费】

软件测试面试文档

我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。

全套资料获取方式：