パフォーマンステストの分析と使用

パフォーマンステストの分析と使用

1. なぜパフォーマンステストを行うのでしょうか?

xx システムは正常にリリースされました。以前のプロジェクトの計画によれば、1,000 社以上の顧客にサービスを提供する予定です。今後、ビジネス システムの情報は大幅に増加する傾向にあることは避けられません。
実稼働環境でシステムがより安定すると、パフォーマンスの問題にさらに集中できるようになります。

  1. どれくらいのデータ量が許容できるのでしょうか?

  2. システムのボトルネックは何ですか?

  3. コードの品質はどうですか?

    これらの質問には、パフォーマンス テストを通じて答える必要があります。

2. 注意すべき点は何ですか?

1. テストの目的を明確にする

性能测试的目的分为两种:
  • 検証: システムが関連するパフォーマンス要件に準拠していることを検証します。例: 500 人の同時リクエストに対応するため

  • 位置付けと調整: テストを通じて関連データを取得し、データを分析、位置付け、調整します。

2. テスト内容の決定

  • ビジネスのポイントと優先順位を明確にする

  • 機能と性能の優先度に応じて業務の優先順位を分け、テストする業務とテストしない業務を決定する

  • さまざまなビジネスやシナリオに関連するパフォーマンス要件 (スループット、応答時間など) を決定します。

3. パフォーマンス テスト カテゴリを理解する

  1. ネットワーク レベルのテスト 現在のテスト

    スループットと応答時間

  2. オペレーティング システムのテスト

    CPU使用率、ディスクスワップレート

  3. データベースレベルのテスト

    データベースの同時接続数、使用されるロック リソースの数、および I/O トラフィックのサイズ

4. 影響を受ける要因

  1. ネットワーク帯域幅: Ali 50M 100M

  2. サーバーの数: Aliyun サーバー

  3. サーバーの CPU、メモリ、およびその他のパフォーマンス(Ali の 2G 8G ソリッド ステート ドライブ、メカニカル ハード ドライブなど)

  4. サーバーOSのバージョン

  5. コードの品質

3. 基本操作

Jmeter はドキュメントのオンライン アドレスを使用します: [https://blog.csdn.net/r657225738/article/details/114981779]{.underline}

1. 単純な http リクエスト

2. カスタム ユーザー変数

3. リクエストデータを抽出してファイルに保存します

シナリオ:バッチ追加、バッチクエリ
必要なコンポーネント: [正規表現抽出ツール -> BeanShell 後処理プログラム] 注:
テキスト エンコーディング: utf-8

4. CSVファイルを使用してデータを読み込みます

シナリオ:一括編集、一括削除

必要なコンポーネント: [CSVデータファイルの設定]

4. データを使って話す

1. コード最適化前後の比較

问题列表-我的问题

ここに画像の説明を挿入


[外部リンク画像の転送に失敗しました。ソース サイトには盗難防止リンク メカニズムがある可能性があります。画像を保存して直接アップロードすることをお勧めします (img-0yyMHUCf-1659577421964)(media/image1.png)] {width="5.751388888888889 "高さ="1.703472222222223インチ"}

2. シングルコピーとダブルコピーのパフォーマンスの差

[外部リンク画像の転送に失敗しました。ソース サイトにはリーチ防止メカニズムがある可能性があります。画像を保存して直接アップロードすることをお勧めします (img-H2vrPJ0r-1659577421966)(media/image2.png)]{width="5.760416666666667in " 高さ = "2.071527777777778in "}

5. 体験概要

1. コード最適化のアイデア

APM リンク追跡を通じて API 操作ログを表示する

  • 1. ライブラリへの不要なアクセスを減らす

    2. 不要なデータ通信を減らす

例: 問題のリスト - アップデート前後の問題

テストとコードチューニングを通じて、全員が注意すべき点が 2 つあります

  • 1. テストツール:同時テスト用のJemter

    2. 問題の場所: 特定の API は、イントラネット APM リンク追跡を通じて最適化コードの方向を見つけます。

結論に達します:

  1. 同時実行テストでは、API 非同期によってパフォーマンスが直接向上します。API が同時実行数 20 で非同期に書き込まれていない場合、スループットは 1 桁ほど低くなる可能性があります。API をタスク非同期に変更した後は、同時実行数 100 で、スループットは達成できます。 150-200

  2. コード内の不要な API アクセスを削除すると、パフォーマンスが向上し続ける可能性があり、パフォーマンスの向上は明らかです (削除された無関係な API アクセスの数に関連します) テストでは、同時実行数 100 で、スループットは 200 ~ 250 に達する可能性があります。

2. パフォーマンステスト時のAPIエラー解決方法

在保证API地址与参数填写正确的情况下,如还报错则为以下两种情况

1. APIレポート500

1.1数据库崩溃,卡死,需要重启

2. API レポート 404

2.1所在企业Api服务卡死,需要重启

6. 知識がほとんどない

6.1 集計レポートのパラメータの意味

  • 最小値: サーバーにリクエストを行ってからデータを返すまでに必要な最小時間を指します。

  • 最大値: サーバーにリクエストした後、データを返すまでに必要な最大時間を指します。

  • 異常値: 異常に切断または接続されるリクエストの割合を指します。

  • TPS (スループット) : 1 秒あたりに処理できるリクエストの数を指します (例: 120/秒、つまり 1 秒あたり 120 のネットワーク リクエストを処理できます。20/分、つまり 1 分あたり)

  • 平均: すべてのリクエストの応答時間の合計の平均を指します。

  • 99% : リクエストの 99% がこの範囲 (354ms / 99% など) を下回っていることを意味します。つまり、リクエストの 99% が 354ms より前に応答を完了します。

6.2 Replicated(コピー)/Scale(スケール)の役割を増やす

1. 自分で理解する:障害が発生したときに Docker が別のノードで新しいインスタンスを作成する時間が短縮され、パフォーマンスが向上し、障害率が減少します。たとえば、現在 3 つのコピー (複製) があり、そのうちの 1 つのコピーが(サーバー) が耐えられない場合は、利用可能なコピーに自動的に転送されます。

2. 専門的な説明:例として、単一のインスタンスを含むコピーを考えてみましょう。さて、障害が発生したとします。Docker Swarm はサービスが失敗したことを認識し、サービスを再起動します。サービスは再起動されますが、再起動は即座に行われません。再起動に 5 秒かかるとしましょう。この 5 秒間はサービスが利用できなくなります。単一障害点。

レプリカに 3 つのインスタンスが含まれている場合はどうなるでしょうか。ここで、そのうちの 1 つが失敗すると (完璧なサービスが存在しない場合)、Docker Swarm はインスタンスの 1 つが利用できないことに気づき、新しいインスタンスを作成します。この間、リクエストを処理する正常なインスタンスはまだ 2 つあります。サービスのユーザーにとっては、ダウンタイムはないようです。このコンポーネントは単一障害点ではなくなりました。

[外部リンク画像の転送に失敗しました。ソース サイトにはリーチ防止メカニズムがある可能性があります。画像を保存して直接アップロードすることをお勧めします (img-FgJWL6sr-1659577421968)(media/image3.png)]{width="5.754166666666666in " 高さ = "0.6125 インチ "}

6.3 スケールスケジューリングルール

将node1宕机后或将node1的docker服务关闭,那么它上面的task实例就会转移到别的节点上。当node1节点恢复后,它转移出去的task实例不会主动转移回来,只能等别的节点出现故障后转移task实例到它的上面。使用命令\"docker node ls\",发现node1节点已不在swarm集群中了。

6.4 高い同時実行性の一般的な意味

たとえば、スナックバーをオープンするとします。

3 人のキャッシャー (Web リクエスト処理スレッド)、5 人のシェフ (データベース接続) があります。

当初、ビジネスは長くは続きませんでした。ゲストも少なくなりました。レジ1台で対応可能です。他はまだアイドル状態です。

その後、ビジネスはますます良くなりました。したがって、3 台のレジはすべて (同時に) 動作しています。

その結果、しばらくして、ネット上の有名人が来て、その店は急に人気になり、大勢の人(同時接続数が高い)が憧れを持ってここに来ました。

その結果、3人のレジ係は有名人の列の前にいて(リクエストはブロックされて列に並びました)、レジ係はロボットではなく、時々注文を間違えることがありました(同時例外)。

後ろのシェフを見ると、注文がどんどん増えています。シェフは料理を作り続けていますが、ますます疲れてきて、料理のスピードがどんどん遅くなっていきます(データベースへの負荷が高く、リクエストの応答時間は長くなります)。

料理が出てくるのが遅いほど、後ろに並ぶ人が増えます(リクエストがブロックされた後の悪循環)。

待たずに帰ってしまったお客様もいて(サービスは時間外でした)、悪い評価を付けられ、気分に影響を与えました(上のレベルのサービスに影響を与えました)。

後ろのシェフはというと、N品作った後、ついに手に負えなくなり、もうできなくなりました(データベース接続が枯渇しました)。

したがって、小規模店は顧客の迎えを一時停止することしかできません (サーバーはリクエストを拒否し、エラー 502 を報告します)。

6.5 スループットレートと同時実行数の共通の意味

ケース 1:スループット レートと同時実行性は、2 つの完全に独立した概念です。銀行のカウンターを例に挙げると、同時接続数とは、同時に何人の人が銀行のカウンターに殺到しているかを表します。スループットレートとは、銀行窓口が一定時間内に対応できる人数を指します。

ケース2: 1昼夜1本の蛇口をひねると10トンの水が出ます; 10本の蛇口を1秒間ひねると0.1トンの水が出ます。もちろん1タップのスループットは大きいです。10個の蛇口よりも1個の蛇口の方が吐水能力が高いと言えますか?したがって、1秒間に誰が最も多くの水を持っているかを確認するには、単位時間を追加する必要があります。これは 0.1 トンの水/秒の処理量です
、エラー 502)。

おすすめ

転載: blog.csdn.net/r657225738/article/details/126153559