平均応答時間の計算: 応答時間のテスト方法

平均応答時間はどのように計算されますか?

平均応答時間 は、特定の時間間隔でターゲット Web サイトでシミュレートされた Web トランザクションの平均時間として計算されます。

平均応答時間 = トランザクション期間の∑時間/ 開始されたトランザクションの数

トランザクションとは何ですか?

トランザクションは、訪問者によってWebリソースに対して実行される一連の完了した操作、または一連のHTTP/Sリクエストと応答として定義されます。 ザ tトランザクション期間の ime です ザ 経過時間, トランザクションが開始された瞬間から その瞬間に トランザクションは、 完了。 例えば, トランザクション 定義可能 として のシーケンス オペレーションズ, Web ページの読み込み、Web サイトへのログイン、別の Webページへの移動、最後にWebフォームの送信など。

ユーザー動作のプロファイルと遅延

ユーザー動作プロファイルを構成すると、一般的なユーザーが Web サイトや Web アプリケーションとどのように対話するかをシミュレートできます。 ユーザーの動作の遅延の詳細については、 ユーザー動作プロファイル のサポート技術情報記事を参照してください。

Web ページのタスク

Web ページ タスクを作成する場合、LoadView プラットフォームは、テスト シナリオで 通常 および カスタム のユーザー動作プロファイルを提供します。 [通常] オプションを選択すると、ページ操作が遅くなり、アクション間にランダムな遅延 (3 ~ 6 秒) が追加され、実際のユーザーが Web サイトを移動する方法をシミュレートできます。 カスタムユーザー動作では、最小遅延と最大遅延を0〜30秒の範囲で設定できます。 遅延時間を最小および最大 0 秒に設定すると、テスト スクリプトができるだけ早く実行されます。 このオプションは、ストレステストのために設計され、システムの応答を確認します(ロードビューの別の機能は 、JMeterのようなオープンソースのパフォーマンステストプラットフォームでは利用できません)。

Web アプリケーションタスク

Web アプリケーション タスクの場合、ユーザーの動作の遅延はトランザクション期間に含まれます。 デバイスを作成したら、特定のデバイスのニーズに合わせてプロファイルをカスタマイズできます。 Web ページのユーザー動作プロファイルと同様に、同じユーザー動作プロファイルオプション [標準 ] と [カスタム] が用意されていますが、特定の Web アプリケーション タスクの要件に基づいて、マウス の移動速度、 マウスのクリック速度、 入力速度など、特定のユーザー アクションをシミュレートするための追加の構成設定が含まれています。 Web アプリケーション のテストの構成の詳細については 、Web アプリケーションロード テスト のサポート技術情報の記事を参照してください。

平均応答時間が重要なのはなぜですか?

ユーザーは、時間や日に関係なく、Web サイトやアプリケーションが常に利用できるようになって、何の挫折も経験せずに実行することを期待します。 読み込みに時間がかかりすぎたり、応答が遅すぎたりすると、ユーザーがすぐに不満を感じ、実行しようとしていたタスクやアクションを放棄し、売上が失われる可能性があります。 わずか 1 秒以上の遅延でも、ユーザーがサイトやアプリケーションから跳ね返るのを防ぐのに違いが生じます。

応答時間に影響を与える要因

パフォーマンス テストを実行すると、問題やボトルネックが発生している箇所を特定するのに役立ちますが、応答時間の遅い処理を実行するのは困難です。 応答時間が遅い場合は、サーバーの過負荷、ホスティング プロバイダーの問題、またはクライアント側の問題が原因である可能性があります。 応答時間が遅くなる要因は多数ありますが、以下のリストは、より一般的な原因のいくつかで構成されています。

複雑な環境

複雑さは、応答時間の低下につながる重要な要素の1つです。 今日のウェブサイトやアプリケーションの多くは、さまざまなサードパーティのサービス、ネットワーク、技術、プラットフォームなどに依存しており、どのような特定のコンポーネントや要素が原因であるかを正確に特定することは困難です。

ヘビー Web ページ

さらに、今日のWebサイトおよびアプリケーションフレームワークは、ページサイズが大きすぎる、JavaScriptが多すぎる、または単に適切に最適化されていない「肥大化した」Webページにつながる可能性があり、ページのパフォーマンスが低下します。 ユーザーにとって人目を引くWebサイトを構築することは重要ですが、Web開発者は、Webサイトとアプリケーションのコンテンツとユーザーエクスペリエンス、およびそれぞれが全体的な応答時間にどのように影響するかのバランスを慎重にとる必要があります。 コンテンツの多いサイトの構築に夢中になることは簡単ですが、ユーザーが早く頻繁にバウンスしている場合は、コンテンツの量と種類を取り戻し、より良いユーザーエクスペリエンスのためにページを最適化することを検討する必要があります。

スケーラビリティ

スケーラビリティは、特にブラックフライデー/サイバーマンデーのような、ピーク時の交通時間や忙しいオンラインショッピング期間中に、応答時間の遅れに寄与するもう1つの重要な要因です。 トラフィックが突然増加すると、サーバーが処理できる数を超える要求を受信し、リソースが使用されるようになるにつれてパフォーマンスのボトルネックになる可能性があります。 パフォーマンス テストは、インフラストラクチャのギャップを特定し、サイトとアプリケーションがユーザーの要求に合わせて拡張できることを確認するのに役立ちます。 需要が高い場合、サーバーは需要を処理するために必要なリソースを適切に割り当てたり増やしたり、需要が減少したときに増やしたりできる必要があります。

ドットコムモニターによる連続監視

Web サイトやアプリケーションの準備が整い、運用環境にプッシュされたら、ユーザーがユーザーエクスペリエンスを低下させないように、読み込み時間と応答時間を継続的に監視することが重要です。 モニタを設定することで、Web サイト、Web アプリケーション、サードパーティのサービスや API が継続的に稼働していることを確認するために必要な洞察とデータを得ることができます。 また、ユーザーとチームが警告を受け取らない場合は、ユーザーの影響を受ける前に問題を解決できます。

Dotcom-Monitor プラットフォームでは、世界中の 30 か所から監視でき、アラート オプション、スケジュール、フィルター、統合など、さまざまなソリューションと機能を提供し、すべてのニーズに対するエンドツーエンドの監視を完全に実現します。 詳しくは、 ドットコム モニタ ソリューションの詳細をご覧ください。