私はテストの分野で10年以上働いており、何らかの方法でストレステストに遭遇しています。 この種のテストに関するさまざまな記事を読み、会議に出席し、この分野で新しくて革新的なことを学ぼうとしました。 受け取る情報のほとんどには、マイクロサービス、データベース、その他のサブシステムを個別にテストするための手順が記載されています。 同時に、サブシステムが適切にチェックおよび構成されている場合、Webシステム全体に十分な注意が払われません。
現在のWebシステムは、さまざまな大陸のさまざまなサーバーに配置できるマイクロサービス、サブシステム、データベースなどのセットです。 しかし、それらはすべて何らかの形でWebベースのインターフェイスと対話します（上で書いたように、現在のバージョンのみを検討しています）。
負荷テストを実行するための多くのユーティリティには、トラフィックを記録する機能があります。 ほとんどすべてのユーティリティは、単一のセッション内で受信したリクエストを順番に記録します。 つまり、リクエストごとのリクエストであり、これらのリクエストがブラウザでどのように実行されるかは気にしません。
接続数と実行シーケンス
最も人気のあるブラウザー（Google Chrome、Mozilla FireFox、Internet Explorer）をいくつか使用して、任意のサイトを開いてみてください。 ブラウザーでの作業の慣習で示されているように、一部のユーザーは並行して開くことができる接続の数を設定し、一部のユーザーはこの数を規制しています。 さらに、化合物の数は、使用する化合物の種類によって異なる場合があります。
Internet Explorer：
Google Chrome：
たとえば、同じhttpsリソースに対して異なる数の並列接続がどのように作成されるかを見ました。 したがって、Google Chromeはこの接続内で6つの接続を作成し、すべてのリクエストを処理しましたが、Internet Explorerは最大20-30の並列接続を作成できました。
ブラウザは複数のスレッドでWebシステムにアクセスし、コンテンツを並行してダウンロードできることがわかります。 ただし、多くのユーティリティはユーザーごとに1つのスレッドのみを実行します。
つまり、パフォーマンステスト用のユーティリティの1つのスレッドが常に1人の実際のユーザーの作業に対応すると言うのは実際には正しくありません。
負荷は、使用されているユーティリティが生成する負荷の数倍になる場合があります。
Webサーバーの設定を見ると、主にワークプロセスの数と開いている接続の数を決定することがわかります。 負荷が実行されるオペレーティングシステムには、開いている接続の数に独自の制限がある場合があります。これは、負荷プロファイルに影響し、Webシステムの動作に関連付けられません。
つまり、各仮想ユーザーは複数の同時接続をサポートできます。 また、1人のユーザーであっても、システムをロードして機能しないようにすることができます。 1人のユーザーに対して1つのスレッドのみを実行する（1つの接続のみをサポートする）ユーティリティを使用する場合、このスレッドは実際のユーザーではないことを理解する必要があります。
サードパーティのリソース
Webシステムはサードパーティのリソースを使用できるという事実に注意する必要があります。 分析、カウンター、提供されたフォント、スタイル、javascriptがあります。 ニーズに応じて、テストする必要があるリソースを自分で決定する必要があります。 サードパーティのリソースでは、一部の情報を初期化でき、後でシステムで使用できます。 したがって、サードパーティのリソースを除外すると、ユーザーに対して完全に受信したコンテンツをシミュレートできなくなります。 必要なクエリのリストは、テスト対象のシステムの長い分析と深い理解によってのみ決定できます。
この図は、リソースに対してリクエストが行われた状況を示しています。リソースがテストされたと見なされ、リクエストとは異なるリクエストが作成されます。 ここで、このリソースがシナリオで必要かどうか、またはWebシステムに接続されていないかどうかを判断する必要があり、単純に除外できます。
グルーピング
実行されたアクションによってリクエストをグループ化する必要があります。 したがって、メインページを開いたり、システムにアクセスしたり、リンクをクリックしたりするために、個別のグループを作成できます。これは、主にアクショングループ間の必要な遅延を設定するために必要です。 1人の仮想ユーザーを、実際にシステムを操作するユーザーと見なします。 当然、100、200、1000、またはそれ以上の実ユーザーがいる場合、それぞれが特定のページで異なる時間を費やします。 したがって、トラフィックは仮想ユーザーから不均等に送信されるはずです。 したがって、アクションのグループ間で遅延を確立する必要があります。 そして、それらがよりリアルであればあるほど、よりリアルなテスト結果が得られます。
おわりに
同時接続、サードパーティのリソース、グループ化、遅延の数は無視できます。 ただし、結果として、システムが200人の仮想ユーザー（スレッド）で動作することが確認できるテスト結果を取得できますが、実際には10人の実際のユーザーしか取得できません。 または、逆の結果を直接取得します。グラフに200人のユーザーしか表示されていない場合、ユーザーはシステムを操作できますが、異なるページの使用時間、使用されている接続の数、サードパーティのリソースの除外を考慮して、500人の実際のユーザーを取得できます。
実行された接続の数、必要なリソースのセットの正しい使用、およびアクションのグループ間の遅延を明確に理解することは、自宅で実行する負荷テストのより正確な結果を得るのに役立つと信じています。
もちろん、これは準備を開始するポイントの完全なリストではありません。 何らかの方法でパフォーマンステストに影響する多くの異なる側面があります。 それらの一部は、ロードを実行するエージェントに直接影響を与える可能性があり、テストされたWebシステムとはまったく接続されない可能性があります。
更新： 記事の準備を続けます
Update2： 記事を完了する