パフォーマンステストは、要求の高いスループットでサーバーを打ち負かすと誤解される場合がありますが、思考時間、ペーシング、遅延などの概念は、実稼働環境で発生する実際のユーザーパターンを達成するのに役立ちます。 現実的なユーザー パターンに近いパフォーマンス テスト シナリオを設計することは、アプリケーションの真の問題やボトルネックを見つける結果を達成するために非常に重要です。 同じコンテキストでは、ロード テスト シナリオを開発する際には、時間とペースが重要になります。 この記事では、考え方、ペース、遅延、および意味、ベスト プラクティス、および LoadViewを使用したロード テスト シナリオの一部としてこれらのメトリックを設定する方法について説明します。 ロード テストに関しては、ロード テストの時間とペースの設定が何を意味するのかを理解しましょう。

思考時間とは何ですか?

負荷テストの待ち時間は、1 人のユーザーの各アクションの時間差です。 アプリケーションを閲覧している間、ユーザーはウェブサイト上で何らかのアクションを実行する前に、ある程度の時間(思考時間)を費やします。 たとえば、電子商取引 ウェブ アプリケーションでは、ユーザーが製品タイルをクリックし、製品表示ページに移動し、このページでコンテンツを使用して読み取るのを待ってから、[ カートに追加 ] ボタンをクリックします。 商品タイルのクリックから カートに追加 のクリックまで費やされた時間は、待ち時間と呼ばれます。 思考時間の値はユーザーによって異なりますが、テスト シナリオでは、平均の思考時間を取ることができます。

通常、負荷テストやストレス テストを考えるとき、ウェブ アプリケーション、ウェブ

サイト、API に対して大量の同時ユーザーを提供して、ストレスの下でのパフォーマンスを確認する方法を考えます。 ストレス テストはパフォーマンス テストに適していますが、実際の実際のシナリオを実際にシミュレートするわけではないため、この種のパフォーマンス テストはユーザーの観点からパフォーマンスを理解するのに適していません。 ここでは、購入パス、製品の検索、アカウントへのログインなど、ユーザーの体験手順をより適切にシミュレートするのに役立つ待ち時間が生まれます。 これらの各ステップは、異なる思考時間値を持ち、ロード テスト時にこれらを考慮することが重要です。

ペーシングとは何ですか?

ペーシングはロードテスト中に使用され、1 秒あたりのトランザクション数でテストが実行されていることを確認します。 これは、ビジネス フローの各イテレーションの時間差です。 これは、1 秒間にサーバーに送信される要求の数を制御するのに役立ちます。 ペーシングは思考時間とは少し異なります。 前述したように、思考時間は反復またはステップ内のアクション間の遅延です。 前述のように、ロード テストは遅延なしでできるだけ多くの要求をサーバーにヒットすることではありません。 さらに、ペースと待ち時間は、ユーザーのエクスペリエンスをより適切にシミュレートするのにも役立ち、より現実的なロード テストを提供します。 通常、イテレーション間には短い期間があるため、ロード テストをセットアップする際に考慮する必要があります。

ロード テスト シナリオに遅延を導入することが重要な理由

完全なステージのロールアウト前にアプリケーションをロード テストすることで、タイムアウト、ページ応答の遅さ、ダウンタイムなどの問題を抱えるエンド ユーザーが直面する潜在的な問題からアプリケーションをテストできます。 現実的なロード テストの結果に近づき、問題を見つけるには、テスト シナリオを可能な限り現実的なものにする必要があります。 テスト シナリオの設計で考える時間とペースを考慮すると、サーバーのキュー管理、スレッド使用率、およびメモリ管理が負荷の高い場合にどのように動作するかをテストできます。 たとえば、各同時ユーザーアクションの間に待ち時間を追加しようとすると、この遅延の間に、サーバーはキューから他の保留中のタスクを選択し、次のタスクを実行してから、古いタスクを再度選択します。 このステップは、実際のユーザーとの運用環境で発生する正確な処理です。 また、待ち時間を追加すると、ユーザーがアプリケーションに費やす時間も増加し、サーバーの同時処理能力に関連する問題が特定されます。

アプリケーションの遅延を計算する方法

同時仮想ユーザー数、遅延数、およびトランザクション/秒 (TPS) の数は、アプリケーションごとに異なります。 したがって、アプリケーションの遅延を計算するには、以下の数式を使用します。

ロード テストの期間 (秒) * (TPS + 遅延) * 同時ユーザー数 = トランザクションの合計

たとえば、100,000 トランザクションを生成し、各トランザクションの応答時間が 5 秒で、テストを 10 分 (600 秒) 実行するとします。 3 秒の遅延時間を想定して、必要な同時ユーザー数を計算してみましょう。 上記の式を使用して、同時ユーザー数を計算できます。 私たちの場合は、約21ユーザーに出てくる100,000/(8 *10 *60)になります。 このようにして、ロード テストに必要な遅延と数を見つけることができます。

ロード テストを実行する前のベスト プラクティス

パフォーマンス テストから最適で最も正確な結果を得るには、ロード テスト中のベスト プラクティスに焦点を当てた以下の質問に答えることを検討する必要があります。

同時ユーザー数

アプリケーションのベンチマークを行う必要がある同時ユーザーの予想について理解する必要があります。

実際のユーザー テスト シナリオのシミュレーション

実際のユーザー体験、ユーザーが費やした時間、および各テスト間の遅延を念頭に置いてテスト シナリオを設計します。

地理分散型仮想負荷

負荷を生成するロード インジェクタは、アプリケーションが世界中からトラフィックを受信することが予想される場合は、特定の地理的位置に基づいて分離する必要があります。

ランプアップ期間の設定

また、ランプアップ期間を設定することで、アプリケーションのスケールを徐々に拡大し、テスト シナリオをアプリケーションの動作にリアルに再現できます。

テスト期間

テストの時間は、サーバーが連続した直線負荷の下に置かれた場合にどのように動作するかを理解するために重要です。

ロードビューでの遅延の追加

LoadView には 、ブラウザーで実行されたアクションを記録することによってテスト シナリオを簡単に作成できる EveryStep Web レコーダーが含まれています。 これは、ユーザーが実行する正確なステップと動作を模倣し、セレクター、アクション、遅延などのすべてのデータポイントを収集します。 テスト シナリオを作成する際には、実際のユーザージャーニーを待ち時間の遅延で模倣する必要があります。 記録を停止すると、必要な同時ユーザーで再実行できるスクリプトが作成されます。 次の図からわかるように、テストに必要な場合は、スクリプトを変更し、個々のステップの遅延を更新することもできます。 EveryStep Web レコーダー スクリプトの編集の詳細については、こちらをご覧ください

遅延をスクリプトに追加する

開発されたスクリプトは、アプリケーションとユーザージャーニーとの実際のユーザー操作を使用して、ロード テストから正確な結果を達成するのに役立つ最良のアプローチと考えられています。

ユーザー動作プロファイル

さらに、LoadView プラットフォームからユーザーの動作を変更するオプションがあります。 下の画像でわかるように 、Normal Delay から選択するか、 カスタム遅延 を選択して、アプリケーションの特定のユーザーの動作と遅延を設定できます。 詳しくは、ユーザーの動作の調整に関する記事をご覧ください

ユーザーの動作を調整する

パーティング思考:負荷テスト:思考時間、ペース、遅延

アプリケーションを運用環境に送る前に、アプリケーションのパフォーマンス テストは重要な側面です。 ベスト プラクティスに従い、アプリケーションの実際のユーザー体験をカバーするテスト シナリオを開発した場合にのみ、これらの正確なパフォーマンス関連の問題を見つけるのに役立ちます。 この記事では、テスト シナリオ設計の作成中に時間とペースの遅延を念頭に置いて、システムの問題の下を見つけるのにどのように役立つかを説明しました。 これは、ページタイムアウト、遅いページ応答、応答時間、サーバーエラーなどの問題を、高負荷で事前に見つけるのに役立ちます。

これらの戦略は、応答性と信頼性の高いアプリケーションやウェブサイトに向けて私たちを助けることができます。 今すぐ EveryStep Web レコーダー を試してみて、アプリケーションのスクリプトをどれだけ早く作成できるかを確認してください。

LoadView に今すぐサインアップ し、ロード テスト クレジットで $20 を受け取ります。 LoadViewプラットフォームに関する質問はありますか? 当社のサポートチームに連絡して、当社のパフォーマンスエンジニアの1人に話をしてください。