ここにディレクトリのタイトルを書きます
1. 性能試験環境の準備
1. パフォーマンステスト環境：サーバー構成
1. ハードウェア モデル: 可能な限り一貫性を保つようにしてください。
2. サーバーの数:
サーバーには 20 台を超えるマシンが存在する場合があります。運用環境、大企業では数千台のマシンさえありますが、サーバーの全数がパフォーマンス テスト環境にリストされていますか?必要ありません
ベンチマーク テスト:
同じことが言えます。
たとえば、1 台のマシンで 1000/秒の同時実行が可能です。理論的には次のようになります。 1,000 台のマシンで 100,000/秒の同時実行を実行できる
ということは、パフォーマンス テスト環境のサーバーの数を厳密に必要とするわけではありません。
2. データの準備
a. 純粋なデータベース SQL
b. コードを使用してデータを生成し、インポートされた SQL ステートメント: より一般的に使用される
ヒント:
既存のデータから派生、
ランダムに生成
c. コード/ツールを使用してインターフェイス/UI 自動生成を呼び出す
注意:
a. データのステータス分布に注意してください
b. たとえば、注文データ - 複数のステータス (運用環境の分散状況)
データ分散によってデータベース レベルのパフォーマンスが決まります
c. 極端なデータ状況ですか?
パフォーマンス テストは、多数のユーザー (ユーザーが分散している) を使用する通常のシナリオに基づいています。パフォーマンス シナリオがビジネス シナリオから切り離されている場合、このようなパフォーマンス テストは必要ありません。
2. パフォーマンステスト実行ツール（Jmeter）
バージョン: 5.4.1
Java 環境に依存: JDK1.8
サードパーティ プラグイン:
次のディレクトリに配置します
apache-jmeter-5.4.1\lib\ext
スレッド モデル: マルチスレッド並列実行
スレッド数: 同時に作業している仮想ユーザーの数。作業の内容はスレッド グループ内の内容です。
複数のスレッドが同時に開始されます
同じスレッドがスレッド グループ内のタスクを実行します。これは順序どおりです。
1. ユーザー定義変数:
2. トランザクションコントローラー:
使用シナリオ: テストするシナリオに複数のインターフェースが含まれる場合、全体的なデータ統計を実行する必要があります。
複数の操作を 1 つのトランザクションとしてカウントできるため、コスト効率が高くなります。 a>
トランザクション内のいずれかの操作が失敗すると、トランザクション全体のステータスが異常実行されます。トランザクション全体のほとんどのインターフェイスに問題はありませんが、1 つのインターフェイスだけでエラーが発生し、トランザクションの実行は失敗します。
3. テスト結果の表示
a. 概要レポート
欠点: 最終結果のみが表示され、プロセスが表示されず、システムがどの段階でパフォーマンスの変曲点に達したかを分析することができません。
ラベル
インターフェース名
サンプル
インターフェースリクエストの数
平均(ミリ秒)
最初のインターフェイスを例に挙げます。合計 1,000 個のリクエストが開始され、各リクエストを加算して 1,000 で割って、平均応答時間を取得します。
最小値(ミリ秒):
最初のインターフェイスの最小長は 10 ミリ秒、2 番目のインターフェイスの最小長は 1 ミリ秒、というようになります。
最大値(ms)
最初のインターフェイスの最大長は 115 ミリ秒、2 番目のインターフェイスの最大長は 15 ミリ秒、というようになります。
標準偏差
float が大きいかどうか、つまり、最初のリクエストと 2 番目のリクエストの間の応答時間の差を示します。
異常な％
インターフェースリクエストエラー数/リクエスト総数
スループット
1 秒あたりの完了リクエスト数、jmeter がリクエストを発行してサーバーがリクエストを処理し、jmeter に返すまでの全プロセスは 1—— 》ビジネス スループット
ホームページ - ホット リスト インターフェイスをクリックすると、システムは 1 秒あたり最大 28.6 リクエストを処理できます
トランザクション全体で、システムは 1 秒あたり最大 19.2 リクエストを処理できます
スループットは tps と qps に分割されません
tps: データ変更シナリオ
qps: データ クエリ シナリオ
受信KB/秒:
ネットワーク受信速度——》ネットワーク スループット
KB/秒を送信:
ネットワーク送信速度——》ネットワーク スループット
平均バイト数
ネットワークスループット
b. グラデーションスレッドグループ
c. グラフィックスプラグイン
3. ユースケース実行プロセス
1. ベンチマークテスト
シナリオ 1: オンライン サーバー リソース プランニング
パフォーマンス ベンチマーク: 各ユーザー操作に必要なリソースとパフォーマンス指標をテストするための同時実行性は非常に低い
ベンチマーク テスト結果分析:
1024KB——》1MB
1024MB——> 1GB
受信 KB/秒: 3341.10KB/秒: ネットワーク帯域幅が 3M で、同時実行が 1 秒あたり 40 リクエストに達できることを意味します
1. ネットワーク スループット (受信) による - サーバー帯域幅が 1 秒あたり 3M の送信をサポートできない場合データは約 40/秒であり、サーバーは 40/秒のスループットを達成できません
2. 1 つのスレッドは 40 の同時実行をシミュレートします。4000/秒の同時実行をシミュレートしたい場合、理論的には仮想をシミュレートするには 100 のスレッドが必要ですユーザー
2. 負荷試験
システムがパフォーマンス要件を満たせなくなるまで、システムの同時実行圧力を継続的に高めます。
応答時間
スループット
リソース使用量
シナリオ 1: オンライン同時実行数は 4000/秒に達すると予想されますが、システムはそれに耐えることができますか?
4000/s: パフォーマンス要件の分析中に取得されます。
勾配圧力試験——》方法
注: 負荷テストの結果が推定結果と異なる場合は、スレッドの数を調整します。
たとえば、理論上のスループット: システム スループット曲線
a、吞吐量模型：
銀行の例を確認し、銀行をシステム プロジェクトと比較します。
この銀行には 10 の窓口があり (システム リソースが限られているため、窓口は増えません)、取引の処理には毎回 1 秒かかります。
最初の 1 秒は 1 でした個人の場合、スループットは 1
2 秒目では 5 人が来て、スループットは 5
3 秒目では 8 人が来て、スループットは 5は 8 a> 5 秒目には 20 人が来ました。スループットは 10 で、残りの人はロビーで列に並んで待っていました。
4 秒目に 12 人が来て、スループットは 10 でした。5 秒以内に 20 人が到着し、最初の 1 秒はすぐに処理されました。次の 10 人は処理されるまでに 1 秒待つ必要がありました -> 応答時間は増加しましたが、スループットは変わりませんでした。これはシステムに問題があることを意味するものではありません。
銀行はすべてのリクエストを 3 秒以内に完了することを約束しています。3 秒を超える場合は、銀行システムをアップグレードする必要があります。
上記に基づくと、スループットは変わりませんが、応答時間は確実に増加します。
最初の可能性
後を追う人が増えれば増えるほど、銀行には足の踏み場がなくなりました。混雑していて息をする空気もありませんでした
最終的には、銀行の窓口係には息をする空気がなくなり、銀行が 1 つになりました。出納係が気絶しました。 、気絶 2...10、システムが崩壊しました。 ——》ここで言う空気とホールはシステムリソースです。
2 番目の可能性:
一定の人数に達すると銀行のセキュリティーが直接ドアを閉め、それ以上の入場はできなくなります。
予想される現象:
第 1 段階: 同時実行性の増加 -> スループットも増加します
第 2 段階: 同時実行性の増加 ——》スループットは横ばいで増加しませんが、 応答時間は長くなります
スループットは変化せず、システムが処理できないと考えられ、新しいリクエストが待機/バックログされます (バックログはリソースを占有し、リソースは限られており、無限のバックログは存在せず、最終的にはクラッシュします)。
第 3 段階 - クラッシュ: 同時実行性の増加 - 》
1. スループットの低下
システムはリクエストのバックログを継続しており、リソースが不足しています。
2. リクエストエラー率の増加
リクエストできません。リクエストがタイムアウトしました
システムが新しいリクエストを拒否します
ベンチマーク概要レポート
1 スレッド——》スループットは 40/秒
アイデア: ベンチマーク テストの結果によると、負荷テスト中: 応答時間はベンチマーク テストと一致し、スループットは 2 倍になるはずです。
負荷テストの概要レポート
60 スレッド——>>スループットは 134/秒、理論的には 40/秒*60 で、理想的な点には達しません。 a> a>
結論:
インターフェースが遅い
4. パフォーマンステストの領域分割の概念
ベンチマーク: 同時実行性が非常に低いシナリオでシステムのパフォーマンス ベースラインを収集します
ベンチマークのスレッド数が 1 なのはなぜですか?
スレッド数の要件: システムが負荷の 100% に耐えられる場合 (2 または 10 の場合もあります)、1 が最小シミュレーション単位です /font>
負荷テスト: 目的は、プログラム システムの実際の処理能力を確認することです。
負荷テスト スレッドの数
ベンチマーク テストによると、各スレッドが 1 秒あたりに何回同時実行をシミュレートできるか。たとえば、ベンチマーク テストでは、1 つのスレッドは 40/秒の同時実行をシミュレートできます。
目標: テストシステムが負荷 4000/s を処理できるかどうか
予備のスレッド数 = ターゲットの同時実行数 / シングルスレッド シミュレーションの同時実行数
5. jmeter関連
1 秒間に 100 個のスレッドを起動して 1 回実行することを意味します。
具体的な作業内容は次のとおりです。
3 人で 3 回作業しました。合計 9 回
これら 3 人が同時に作業しました
サイクル数: 各スレッドが作業する必要がある回数を示します
jmeter の実行順序
1. 同じスレッドの場合、http リクエストは連続しており、最初にタスク 1 を実行し、次にタスク 2 を実行します。
2.これら 2 つのタスクを同時に実行する 3 つのスレッドがあり、順序はありません。
おそらくスレッド 1 がタスク 2 を実行し、スレッド 2 がタスク 1 の実行を開始した可能性があります。
