記事ディレクトリ
I. 概要
1.1 目的
このテストレポートは、Web チャット ルームのパフォーマンス テスト レポートであり、パフォーマンス テスト段階での学習を要約し、テスト結果を分析し、Web サイトが要件を満たしているかどうかを説明することを目的としています。
1.2 背景
ユーザー数やデータ量の増加により、サーバーに計り知れない負荷がかかることを考慮し、Web チャットルームプロジェクトの負荷性能をテストする予定であり、システム構成を変更しない条件で、サーバーが一定時間内に高負荷状態にある場合の動作パフォーマンス。システム環境の正確な分析と評価を容易にします。
1.3 範囲
このテストは主に Web チャット ルーム プロジェクトのパフォーマンス テストです。
2 つのテスト環境
| 環境 | マシンタイプ | オペレーティング·システム | カップ | メモリー |
|---|---|---|---|---|
| クライアント | ラップトップ-Q4342TA2 | ウィンドウズ10 | i5-11300H(x64) | 16.0GB |
3つの試験内容と方法
3.1 テストの目的
多数のユーザーとデータ量の過負荷の下で、実行中のサーバーの関連データを取得し、分析してシステムのボトルネックを特定し、システムの安定性を向上させます。
3.2 テスト内容
本テストは、主にWebチャットルームの「ログイン機能」の高負荷時の応答速度と耐荷重をテストするものです。
3.3 テスト ツール
主なテスト ツールは次のとおりです: JMeter パフォーマンス テスト ツール
補助ソフトウェア: スクリーンショット ツール、Word
GUI テストの 4 つのステップ
4.1 新しいスレッドグループを作成する
関連パラメータを設定します。 1. スレッド数 (仮想ユーザーの数) 2. ランプアップ時間 (秒): すべてのユーザーの起動時間を設定します。 3. サイクル時間: 各スレッドによって送信される数
ここでは、まず 1000 * 3
4.2 を設定して、新しい HTTP リクエストを作成します。
インターフェイスドキュメントに従って、テストのインターフェイス情報とパラメータを入力します
4.3 適切なアサーションを追加する
インターフェイスのドキュメントを見ると、応答が成功した場合は "success":true という文字列が含まれることがわかったので、対応する設定を追加します。
アサーション結果を追加します。
4.4 リスナーの追加
ここでは、結果ツリー、集計レポート、およびグラフ結果を表示することを選択します。
4.5 を実行して
、結果ツリーを表示します。
集計レポート:
グラフ結果:
しかし、テスト中に、Jmeter を実行しているコマンドラインでこの文を突然見つけました。グラフィックス ツールも多くのリソースを消費するため、単純なデータ ライター + HTML レポート ダッシュボードを使用して再度テストしました。
5 つのシンプルなデータ ライター + HTML レポート ダッシュボード
4.1 データスケールを再度変更する
テスト圧力を上げ、スレッド数を 1000 に変更し、10 回ループします。
5.2 単純なデータ ライターを追加します。
出力パスを適切なディレクトリに変更し、ファイルのサフィックスを jtl 末尾に変更します。
5.3 HTML レポートを生成します。
「レポートの生成」をクリックします
5.4 レポートの表示
6つの結果分析
6.1 成功率
ダッシュボードでは、このテストの成功率が 90.06% であり、成功率が比較的低いことがわかります。
6.2 応答時間の変動
ここでは、テスト要求時間が 200,000 ミリ秒以上という恐ろしい値に達しており、ユーザーにとっては耐えられず、システムの応答が期待に応えられないことがわかります。
6.3 TPS
1秒あたりに処理されるトランザクション数も減少傾向にあることがわかります。
6.4 応答時間
システム全体の応答時間が非常に遅いことがわかります。
6.5 エラーメッセージ
ここには多くのエラー メッセージがあり、SocketException が 80% に達していることがわかります。
7 つのパフォーマンス最適化スキーム
1. サーバー リソースの制限:サーバーの処理能力は限られており、同時に多数の同時リクエストを処理できません。同時リクエスト数がサーバーの処理能力を超えると、アクセス速度の低下やエラーが発生します。パフォーマンス テストでは、TOP コマンドを使用して、サーバーの CUP が常にいっぱいで、一度に大量のリクエストを処理できないことを確認します。解決策としては、CPU を増やすなど、サーバーのハードウェア リソースを増やすことが考えられます。 、メモリまたは帯域幅。
2. コードのビジネス ロジックを改善します。ログイン時に画像検証コードをサーバーのハードディスクに保存するシングルスレッド操作があるため、このステップは同時実行性が高い場合には非常に時間がかかり、マルチスレッド操作を導入することができます。後で。
3. データベースの負荷:インターフェースはデータベース内の検証コード ID を読み取る必要があり、同時実行性が高い場合、データベースの負荷が増加し、アクセス速度が遅くなったり、エラーが発生したりする可能性があります。データベースへの負荷は、データベース クエリの最適化、データベース インデックスの増加、キャッシュ テクノロジ、およびサブデータベースのサブテーブルの使用によって軽減できます。
4. WebSocket プロトコルの正しい使用:パフォーマンス テスト中に大量の SocketException が発生しましたが、その後の調査と修正を的を絞った方法で実行できます。