パフォーマンステストのヒント

スクリプトを設定可能なシナリオに分割します。次に例を示します。

• ホームページを開く

• カテゴリページを開く（PLP）

• 簡易製品（PDP）の表示 – 各反復内の 2 つのループ

• 設定可能な製品の表示 – 各反復内の 2 つのループ

  • 例えば、上記の手順をトラフィックの 60% に設定します

• 製品検索

  • 例えば、カタログ検索をトラフィックの 37% に設定します

• 買い物かごとチェックアウト

  • 例えば、スクリプトの「買い物かごとチェックアウト」部分を完了するユーザーは、デフォルトで業界標準の e コマースサイトのコンバージョン率を約 3% に設定する必要があります
  • チェックアウトフローはキャッシュされず、通常はリソースを大量に消費する操作なので、注文件数とサイトブラウザー数の比率を非現実的に高い数値に設定すると、サイトで処理できるトラフィック量の信頼性が低い結果になります。

各テストの実行前に、すべてのキャッシュをクリーンアップします。

• AEM Dispatcher キャッシュは完全にクリーンアップする必要があります
• Adobe Commerce Fastly と内部キャッシュは、完全にフラッシュおよびクリーンアップする必要があります。これは、Adobe Commerce管理のキャッシュコントロールを使用して行うことができます。

Jmeter テストにランプ期間を含める：ランプ期間を設定しない場合、トラフィックを徐々に増やすことはなく、一般的に訪問されるページやページのコンポーネントをサイトがキャッシュする機会がないことを意味します。 実際の場合、すべてのピークトラフィックが完全にキャッシュされていないサイトに同時に到達するのは通常ありません。そのため、Jmeter テストスクリプトにランプ期間を含めて、実際の e コマースサイトで発生するようにキャッシュを構築できるようにする必要があります。

イテレーション内の各ステップ間の「待機時間」は使用する必要があります。実際には、ユーザーは使用しません
ジャーニー中にすぐにサイトの次のページにジャンプします。ユーザーがページを読んで次のアクションを決定するまで、待機時間が発生します。

無限にループするようにスレッドグループを設定しても、設定された時間 x （例：60 分）が経過した場合には、繰り返し可能なテストが行われ、前回のテスト実行に対する応答時間の中央値が得られます。 つまり、設定ランプアップ期間の後は、同時に実行される仮想ユーザーの目標数が発生し、設定されたループ時間が継続されます。

平均時間は、平均ではなく、平均応答時間の改善/低下を示すために使用する必要があります。 次の場合
他の結果よりも時間がかかるエッジ結果がいくつかあるため、この平均結果はゆがむことになりますが、大部分のユーザーのエンドユーザー応答時間に興味を持っているものがあり、これは中央値の測定により適しています。

埋め込みリソースは、デフォルトでは jmeter で収集されません（例：実際のユーザーがページにアクセスしたときにダウンロードされる JS、CSS、その他のリソース）。 これを有効にすることができますが、テスト対象のドメインに対してのみ、外部リソース呼び出しを引き続き除外する必要があります（例：外部でホストされるサービスからの応答時間を含めない）。 google analytics コード（アドビでは制御できないので）。

HTTP キャッシュマネージャーを有効にする必要があります。これにより、ジャーニー中のページ要素が次のように Jmeter によってキャッシュされます
実際のユーザーのジャーニーは、ユーザーが自分のブラウザーで web サイトを閲覧する際に行われます。 サイトを介したジャーニー中、ユーザーのブラウザーは関連する埋め込みリソースを 1 回だけダウンロードし、ユーザーのブラウザーによってこれらがキャッシュされます。 また、同じユーザーが元の訪問の後にサイトに戻った場合、それらのアセットがキャッシュされるのは、キャッシュである可能性があります。

リスナーは、実際のロードテストの実行内（「結果ツリーの表示」や「集計レポート」など）に保つ必要があります。 非 GUI の実際の負荷テストの実行にこれを含めると、レポートを生成するために実際のテストの実行中にリソースが使用されるので、Jmeter によってレポートされるパフォーマンス結果に影響を与える可能性があります。 これらのリスナーは、テストスクリプトから削除され、JTL 結果ファイルに置き換えられました。このファイルは、Jmeter のレポートダッシュボード機能を使用して処理できます。

ダッシュボードレポートの「Apdex スコア」を、テスト実行間のパフォーマンスに対する変更の影響を測定する簡単な方法として使用できるように、の評価対象の応答時間。 Apdex スコアは、許容できる時間内にサイトにアクセスできる特定の人数に基づいています。 応答時間が特定の「不満」な量を超えると、スコアが低くなります。 時間は、「apdex_satisfied_ threshold」および「apdex_tolerated_threshold」パラメーターを使用して設定できます。

仮想ユーザー数ではなく、ビジネスユーザーに提示するターゲットの「1 時間あたりの注文件数」指標を設定します。 「仮想ユーザー」は、実際にテストで何が測定されているかを理解するための複雑なトピックになる可能性があります。 サイトのコンバージョン率、1 時間あたりの注文数、ユーザーがサイトに滞在する平均時間、および各ページ読み込みの間の思考時間を計算することで、業界標準の計算を使用して、1 時間あたりの注文数に基づいて、様々な読み込みテストシナリオを提示できます。

最後に、Jmeter テストサーバーは、ユーザートラフィックの大半の送信元とクラウドインフラストラクチャがホストされている地理的に近いサーバーで実行する必要があります。これらが同じであることを願っています。