平均応答時間はどのように計算されますか?
平均応答時間 は、特定の時間間隔でターゲット 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 アプリケーション タスクの要件に基づいて、speedを入力します。 Web アプリケーション のテストの構成の詳細については 、Web アプリケーションロード テスト のサポート技術情報の記事を参照してください。
平均応答時間が重要なのはなぜですか?
ユーザーは、時間や日に関係なく、Web サイトやアプリケーションが常に利用できるようになって、何の挫折も経験せずに実行することを期待します。 アプリケーションやサイトの読み込みや応答に時間がかかりすぎる場合、ユーザーは、すぐに不満を感じ、実行しようとしているタスクやアクションを放棄し、売上が失われる可能性があります。 わずか 1 秒以上の遅延でも、ユーザーがサイトやアプリケーションから跳ね返るのを防ぐのに違いが生じます。
応答時間に影響を与える要因
パフォーマンス テストを実行すると、問題やボトルネックが発生している箇所を特定するのに役立ちますが、応答時間の遅い処理を実行するのは困難です。 応答時間が遅い場合は、サーバーの過負荷、ホスティング プロバイダーの問題、またはクライアント側の問題が原因である可能性があります。 応答時間の遅れに寄与する要因は数多くありますが、以下のリストは、より一般的な原因の一部を含みます。
複雑な環境
複雑さは、応答時間の遅れにつながる重要な要因の 1 つです。 今日のウェブサイトやアプリケーションの多くは、さまざまなサードパーティのサービス、ネットワーク、技術、プラットフォームなどに依存しており、どのような特定のコンポーネントや要素が原因であるかを正確に特定することは困難です。
ヘビー Web ページ
さらに、今日のウェブサイトやアプリケーションのフレームワークは、ページサイズが大きすぎる、JavaScriptが多すぎる、または単に適切に最適化されていない「肥大化」したウェブページを引き起こし、ページのパフォーマンスが低下する可能性があります。 Web 開発者は、ユーザーに目を引く Web サイトを構築することが重要ですが、Web 開発者は、Web サイトとアプリケーションのコンテンツとユーザー エクスペリエンスのバランスを慎重に調整し、各 Web サイトが応答時間全体に与える影響を慎重に調整する必要があります。 コンテンツの多いサイトの構築に夢中になることは簡単ですが、ユーザーが早く頻繁にバウンスしている場合は、コンテンツの量と種類を取り戻し、より良いユーザーエクスペリエンスのためにページを最適化することを検討する必要があります。
スケーラビリティ
スケーラビリティは、特にブラックフライデー/サイバーマンデーのような、ピーク時の交通時間や忙しいオンラインショッピング期間中に、応答時間の遅れに寄与するもう1つの重要な要因です。 トラフィックが突然増加すると、サーバーが処理できる数を超える要求を受信し、リソースが使用されるようになるにつれてパフォーマンスのボトルネックになる可能性があります。 パフォーマンス テストは、インフラストラクチャのギャップを特定し、サイトやアプリケーションがユーザーの要求に応じて拡張できることを確認するのに役立ちます。 需要が高い場合、サーバーは、需要を処理するために必要なリソースを適切に割り当てるか、または増加し、需要が減少したときに下がる必要があります。
ドットコムモニターによる連続監視
Web サイトやアプリケーションの準備が整い、運用環境にプッシュされたら、ユーザーがユーザーエクスペリエンスを低下させないように、読み込み時間と応答時間を継続的に監視することが重要です。 モニタを設定することで、Web サイト、Web アプリケーション、サードパーティのサービスや API が継続的に稼働していることを確認するために必要な洞察とデータを得ることができます。 また、ユーザーとチームが警告を受け取らない場合は、ユーザーの影響を受ける前に問題を解決できます。
Dotcom-Monitor プラットフォームでは、世界中の 30 か所から監視でき、アラート オプション、スケジュール、フィルター、統合など、さまざまなソリューションと機能を提供し、すべてのニーズに対するエンドツーエンドの監視を完全に実現します。 詳しくは、 ドットコム モニタ ソリューションの詳細をご覧ください。