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

思考時間とは何ですか?

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

通常、負荷テストとストレス テストについて考えるときは、Web アプリケーション、 ウェブ サイト、または 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 にサインアップして、無料のロード テストを受けてください。 LoadViewプラットフォームに関する質問はありますか? 当社のサポートチームに連絡して、当社のパフォーマンスエンジニアの1人に話をしてください。