重要なポイント
- ロード テストは、本格的な DevOps 計画の重要な部分であり、定期的に実施する必要があります。
- ロード テスト メトリックは、開発チームが Web サイトウェブ と ウェブ アプリケーションの問題を切り分け、効率的に作業して、大規模なユーザーに可能な限り最高のエクスペリエンスを提供するのに役立ちます。
探しているものを明確に理解せずにロード テスト プロセスに入ると、テスト結果を見るときに必然的に混乱が生じます。 あなたと開発チームが先に進んで変更を実装し、ユーザーにとって有意義な改善を行う前に、ロード テストの結果の意味を十分に理解することが不可欠です。
この投稿は、 ウェブ 大規模に、デバイス間で、世界中のユーザーにとってシームレスで優れたものにするためのガイドに役立ちます。
定期的な負荷テストの利点
定期的なロード テストの利点のいくつかは、次の統計で示されています。
- Shopzillaはページの読み込み時間を7秒から2秒に短縮し、コンバージョン率が7%-12% に向上しました
- また、読み込み時間を25秒短縮することで、ページビューを5%増加させました。
- また、ノード数を50%(402〜200ノード)削減して同じボリュームをサポートでき、サーバーコストを半分に削減
- Amazonがページの読み込み時間を+ 100ミリ秒増加させた場合、売上の1%が失われます(+100ms === 1マーケティングピクセル/サードパーティスクリプト)
- Googleがページの読み込みを+500ミリ秒増加させた場合、検索数は25%減少します
- Firefoxが読み込み時間を2.2秒短縮した場合、ダウンロードコンバージョンが15.4%増加しました
- Netflixは、圧縮を有効にした後、アウトバウンドトラフィックが43%減少しました
- オンライン買い物客の52%は、サイトへの忠誠心にとって迅速なページ読み込みが重要であると主張しています
これらはあなたが目を光らせる必要があるほんの数例です。 より詳細な分析については、この記事の詳細を読み、ロード テスト メトリックの詳細を確認してください。
知っておくべきロード テスト メトリック
パフォーマンスメトリックは、 ウェブ サイトのパフォーマンスを監視できます。 ウェブ サイトがユーザー側でどのように動作するか、およびサーバーが処理できるボリュームの量を知ることができる必要があります。 それぞれに異なるメトリックがあります。
平均応答時間
ユーザーが最初に要求を作成したときと、結果が配信された終了時刻の時間の差を平均して、「平均応答時間」を求めます。 ウェブ サイトの平均応答時間を知ることは、ロード テストの成功、ひいてはビジネスの成功にとって重要です。
ユーザーは即効性の ウェブ サイトを好み、 ウェブ サイトのサービスによって速度が低下すると、すぐに競合他社にジャンプします。 ウェブ サイトの平均応答時間を学ぶことで、サーバーのパフォーマンスに関する洞察が得られます。 それはあなたがより効率的なものに投資する必要があるかどうか、またはあなたが成功するために必要な結果を得るためにあなたの現在のものを再調整する必要があるかどうかを教えてくれます。
訪問者の経験と自信に関するいくつかの研究は、イギリスでは、オンライン買い物客の67%が遅い ウェブ での購入を放棄する可能性が高いことを示しています。 ウェブ サイトの読み込み時間を1秒でも改善すると、eコマースのコンバージョン率が10〜20%向上します。 さらに、Akamai が 2017 年に作成したオンライン小売パフォーマンスレポートによると、全消費者の最大半数が携帯電話でサービスや製品を閲覧しており、100 ミリ秒という短い遅延でもコンバージョンが 7% 低下する可能性があります。
つまり、応答時間はeコマースとオンラインリード生成の両方に不可欠です。 ユーザーは何百万ものオプションをすぐに利用でき、Webサイトまたはウェブ アプリケーションのパフォーマンスウェブ が遅い場合は、結果として収益が失われる可能性があります。
ピーク応答時間
平均応答時間が ウェブ サイトのパフォーマンスの概要を示している場合、ピーク応答時間は詳細への洞察を提供します。 ピーク応答時間は、サーバーがユーザーの要求に対する応答を生成するのにかかった最長時間の測定値です。 ピーク応答時間の知識は、気になる可能性のある特定のコンポーネントに関連する質問に答えます。
Web ウェブ には、ピーク応答時間を測定することが重要です。 機能不全の支持者が長引くと、その結果はシステム全体とビジネス全体に壊滅的な打撃を与える可能性があります。
遅い ウェブ サイトでは、トラフィックが減少します。 Googleは、ユーザーの最大53%が、読み込みに3秒以上かかる ウェブ サイトを放棄する可能性が高いと報告しています。 5 秒を超えると、ユーザーがページを放棄する可能性は 90% に増加します。 10秒で、バウンスの確率は123%と大幅に増加します。
遅いサイトはまた、コンバージョンを損ない、ユーザーが再び訪問して購入する可能性を減らし、収益に何年も続く可能性のある下流の影響をもたらします。 さらに悪いことに、Googleや他の検索エンジンは、パフォーマンスの遅いサイトはユーザーエクスペリエンスにとってひどいことを理解しているため、遅いサイトにはアルゴリズムのランキングが低くなります。 あなたの遅い ウェブ を見る人が少なくなるだけでなく、彼らはそれにとどまる可能性が低くなり、戻ってくる可能性はさらに低くなります。
エラー率
エラー率は、成功した要求と失敗した要求の比率として出てきます。 100 件の要求ごとに 5 つのエラーが発生すると、エラー率は 5% になります。 ウェブ サイトが容量に近づくと、それに比例してエラーが増加すると予想できます。 あなたの ウェブ エラー率はあなたの ウェブ がどれほど効率的であるかを教えてくれます。
エラー率は、 ウェブ サイトが長期的に機能するかどうかを決定します。 あなたの ウェブ を成功させ、持続可能にするために、定期的にロードテストをすることは申し分のないことです。 ロード テストを定期的に行うと、低負荷と高負荷で ウェブ サイトのパフォーマンスがどのように変化するかをグラフ化できる複数の座標が得られます。
同時ユーザー数
このメトリックは、任意の時点でアクティブなユーザー数に対する ウェブ サイトのパフォーマンスを測定します。 これは、多数のユーザーが同時にサインオンすることが予想される ウェブ サイトにとって特に重要になります。 このようなシナリオは、たとえばワールドカップの試合がストリーミングされるときに、ストリーミング ウェブ サイトで発生する可能性があります。
同時ユーザーのメトリックは、1 秒あたりの要求数 (RPS) のメトリックとは少し異なります。 RPS はサーバーに送信された要求の数を測定しますが、同時ユーザーは ウェブ サイト全体に存在するユーザー数の測定値です。
同時ユーザーのアイデアを持つことはあなたに現実感を与えます。 実際の運用環境では、 ウェブ サイトに同時に複数のユーザーが存在します。 それぞれに独自の動作があり、これによりテストに関する複雑さが増します。 同時に、ロード テスト ツールがエミュレートできる動作が複雑になるほど、その結果はより現実的になります。
スループット
スループットは、特定のアプリケーションが特定の時間 (秒、分、または時間) に対応できる要求の数の尺度です。 テストを開始する前に、正確で信頼性の高い結果を得るために、現実的なパフォーマンス スループット目標を設定することが重要です。 スループットは、サーバーとユーザーのデバイス間を移動するデータの量を把握します。 スループットを測定することで、ユーザーに対応するために必要な帯域幅の量がわかります。 トランザクションが消費する帯域幅の量を理解することが重要です。 ロード テストは、まさにそれを理解するのに役立ちます。
ロード テストのすべてのニーズに LoadView を使用する
LoadView は、Web サイトおよび ウェブ アプリケーション向けの業界をリードするロード テスト プラットフォームウェブ であり、メトリックの読みやすさが高いため、すばやくロード テストを行い、人間が判読できる結果を得ることができます。
注意すべきパフォーマンス メトリックがわかったので、 ウェブ サイトのロード テストを開始できます。 私たちはあなたが待つことができないことを知っているので、私たちはあなたが始めるのを助けるために 無料トライアル を提供します。 無料トライアルにご納得いただけない場合は、1 対1のデモを予約することもできます。