負荷テストとストレステスト
負荷とストレステストの比較
ロード テストは、定義上、予想される負荷の下でシステムのパフォーマンスを測定します。
これに対し、ストレス テストはシステムを過負荷状態にして、ブレークポイントを見つけます。
相違点を調べる:
負荷とストレス テスト
ロード テストは、システムに対して指定された数の要求を実行して、特定のレベルの同時要求でシステムの機能をテストするための計画テストです。 ロード テストでは、Web システムが予想されるトラフィック量を処理できるため、ボリューム テストと呼ばれることがあります。 ロード テストの目的は、システムが期待されるボリュームを、許容可能なパフォーマンス低下まで最小限に抑え、処理できることを証明することです。 許容可能なパフォーマンス低下のしきい値は、ユーザーがサイトから跳ね返らないように、エンド ユーザーに許容可能と見なされる値としてテスターによって定義される必要があります。
ストレス テストは、パフォーマンスが低下する時点を過ぎてシステム上の同時要求の数を増やすために設計されたテストです。 ロード テスト ( または API テスト) が同時ユーザー数でピークに達した場合、基本的なストレス テストは、リソースが過負荷になるまでシステムの負荷を増加し続けます。 これにより、システムが障害を起こす可能性のある状態にまでシステムが押し込まれ、システムがどのように処理されるか、およびシステムが正常な回復を実行できるかどうかを確認できます。
ロード テストとストレス テストのこれらの定義の中で、それらが互いに完全に独立しているわけではないことが分かります。 多くの場合、ロード テストの上限を実行すると、有効なストレス テストが実行され、システムが使用可能なリソースの制限を超えてプッシュされる場合があります。 この時点で、ストレス テストの実行時に通常見られるエラーと同じ、ロード テストの失敗が表示され始める場合があります。
ロード テストとストレス テストの違いの 1 つは、実際のユーザー トラフィックをシミュレートするために、ロード テストに一時停止を挿入する可能性があるという点です。 ストレス テストを使用すると、できるだけ多くの同時ユーザーを実行して、ストレス テスト用に過剰なトラフィックを生成できます。
負荷テストの目標は、ストレス テストの目標とは大きく異なります。 ロード テストを実行して、Web サイト、Web アプリケーション、または API が特定の数のユーザーを一度に処理できることを確認します。 負荷テストは、キャパシティプランニングのプロセスで頻繁に使用され、システムが指定されたレベルの同時トラフィックに対する拡張を確実に処理できるようにします。
ストレス テストは、システムを意図した容量を超えて、速度の低下を開始し、システムのボトルネックを特定し、潜在的なボトルネックや障害点を明るくするために、システムを具体的にプッシュするために使用されます。
ロード テストは通常、インフラストラクチャでサポートされるとわかっている同時ユーザーの数をテスト システムが開始する一連の手順として実行されます。 これにより、テスト全体で同時ユーザー数が増加すると、参照するパフォーマンス・データのベースライン・セットが確立されます。 パフォーマンス テストは、接続速度の平均、平均待機時間、固定サイズ以上のファイルのダウンロード時間など、いくつかの異なる基準を決定するのに役立ちます。
ベースライン パフォーマンス値がわかっている場合、サンプル期間中に実際にサイトを訪問することが予想される数にユーザー数が増加します。 テストは、多くの場合、システムが新しい負荷レベルで安定した後、ウェブサイトの安定性を確認するために数分間、その静的な数のユーザーで実行されます。
ベースライン テストとベンチマーク テストという用語は、しばしば同じ意味で使用されていますが、この 2 つの用語には違いがあることに注意してください。 ベースライン テストを実施して、サイトまたはアプリケーションのパフォーマンスが時間の経過と同時に低下しないようにします。 たとえば、ベースライン テスト中にパフォーマンス メトリックが記録されるため、将来そのアプリケーションまたはサイトが更新されたときに、エンジニアは新しいパフォーマンス メトリックをテストし、以前のメトリックと比較できます。 これらのベースライン テストには、新しいコード、ソフトウェア、ハードウェア、およびネットワークの変更も含まれます。 目標は、一貫したアプリケーションまたはサイトを提供することです。
ベンチマーク テストは、アプリケーションのパフォーマンスを、事前に定義された業界や組織の標準や要件と比較する方法です。 ベースライン テストと同様に、ベンチマーク テストには、ハードウェア、ソフトウェア、およびネットワークの状態のパフォーマンスの測定と記録が含まれます。 ベンチマーク テストは、組織の要件や他の組織に対するサービス品質を測定するのに役立ちます。 これらのメトリックは、組織の SLA (サービス レベル アグリーメント) を作成し、ユーザーまたは顧客に保証されたサービス レベルを提供するのに役立ちます。 ベースラインおよびベンチマークテストの詳細を参照してください。
負荷テストとストレス テストの間にベースライン パフォーマンス メトリックを確立する場合の 1 つの違いは、ベースラインとピーク パフォーマンスの違いが、ピーク負荷を処理するための適切なシステムがあるかどうかを判断するのに役立ちますが、ストレス テストでは、システムがストレスを受けるポイントについてより懸念されます。 でも、適切に動作しなくなります。
Web アプリのボトルネックを特定するための負荷テストまたはストレス テスト
Web ベースのアプリケーションは、通常、ブラウザで実行され、非同期的な性質のために適切にプログラムされると、数百または数千の同時ユーザーを処理する場合があります。 システムの容量内で予想される負荷を生成する場合、アプリケーションの応答時間は生成されたガイドライン内に留まる必要があります。 これらの制限を超えてシステムをプッシュすると、ストレステストの領域に移動し、意図的にシステムに負担をかけ、故障したコンポーネントを特定します(これは JMeterなどのオープンソースツールで行われることが多いです)。 したがって、ボトルネックを特定するために実行されるテストは、通常、ストレス テストと見なされます ( API テストや API 監視とは異なります ) 。
容量計画のロード テスト
Web アプリケーションの負荷を増加させることにより、今後のユーザー負荷が高くなるアプリケーションのパフォーマンスを予測できます。 アプリケーションが SLA パラメータ内で応答する場合、そのようなテストはキャパシティ プランニングの成功コンポーネントと見なされます。 テスト中に記録されたパフォーマンス メトリックが望ましいパラメーターの外にある場合、システムを使用可能な容量を超えてシステムをプッシュすると、ロード テストがストレス テストになる可能性があります。
ストレス テスト Web アプリ インフラストラクチャ
インフラストラクチャ内の各コンポーネントが失敗するポイントを特定することは、スケーラブルな Web アプリケーションを維持するうえで重要な部分です。 効果的なストレス テストを使用すると、一連の異なるテストを使用して各コンポーネントを分離し、そのコンポーネントの障害発生点を特定できます。 このようなテストには、次のようなものがあります。
- 特定の地域へのすべてのトラフィックを分離する。
- 使用可能なディスク領域を人為的に制限する。
- 1 つの特に大きな GET 要求を繰り返し送信します。
- データ接続の最大数を制限する。
- 大きなイメージ ファイルをダウンロードしています。
- データベースに大量に書き込む強烈な POST を繰り返し送信する。
各テストは、インフラストラクチャの特定のコンポーネントにストレスを与え、障害のポイント、障害率、およびシステム容量の上限を特定するように設計されています。 ストレステストは、ウイルスマーケティング、国際的なニュース認識、ブラックフライデーなどの重いオンラインショッピングの日などから短い激しい負荷の間にボトルネックを特定するのに役立ちます。
ストレス テストは通常、システムの 1 つの部分または別の部分を最大限に引き出し、最終的に速度低下を引き起こし、クラッシュまたは応答を停止します。 テスト中に最初に問題が発生するコンポーネントを決定することが重要です。 このため、ストレス テストを実行する際に監視する必要があるコンポーネントがいくつかあります。 アプリケーション、ソフトウェア、または環境/システムで使用されているテクノロジによって、ストレス テストで測定するメトリックは異なる可能性があることは注目に値します。
- 応答時間: 要求が送信された後に応答を受信するのにかかる時間。 これは、ユーザーが認識する応答時間を測定する場合に特に重要です。
- ハードウェアの制約: これには、CPU 使用率、RAM、ディスク I/O の監視が含まれます。 応答時間が遅れたり遅くなったりすると、これらのハードウェアコンポーネントが潜在的な原因となる可能性があります。
- スループット: テスト期間中に送信/受信されるデータの量は、帯域幅レベルに基づいて行われます。
- データベースの読み取りと書き込み アプリケーションで複数のシステムを使用している場合、ストレス テストによって、どのシステムまたはユニットがボトルネックになっているかを示すことができます。
- データベース接続を開く: 大規模なデータベースは、パフォーマンスに深刻な影響を与え、応答時間が遅くなる可能性があります。
- サードパーティコンテンツ: Web ページとアプリケーションは、多くのサードパーティ製コンポーネントに依存しています。 ストレス テストを行うと、ページやアプリケーションのパフォーマンスに影響を与える可能性のあるテストが表示されます。
サーバー側に適切な監視システムが配置されていない場合、Dotcom-Monitor プラットフォームは、エンドツーエンドのサーバー パフォーマンスを完全に 監視するためのパフォーマンス カウンター監視ソリューション を提供します。 これらのパフォーマンス カウンタは、Windows、Linux、または SNMP (簡易ネットワーク管理プロトコル) のパフォーマンス カウンタを監視するために、サーバーに直接インストールされます。 また、デバイスやサーバーからカスタム パフォーマンス カウンタを監視するソリューションもあります。 パフォーマンス カウンタの監視の詳細については、パフォーマンス カウンター監視ソリューションのページを参照してください。
これらの項目に関する問題は、次のように表示されます。
- 最初のパケット応答が遅い。
- GET/POST 要求と応答の間に大幅な遅延が発生しました。
- 通常のページ読み込み時間よりも長い。
- Web ページの読み込みがタイムアウトしました。
- サーバー エラー コードが返されました。
ロード テスト中にこれらの問題は最初に検出される場合がありますが、ロード テストの背後にある考え方は、システムが定期的に処理できる必要がある予想される負荷をシミュレートすることです。 負荷の増加にリソースを割り当てている間にシステムが一時的に減速する場合もありますが、ほとんどの場合、システムは最初の割り当てから回復し、ロード テストの下で通常のパフォーマンスを再開できる必要があります。
ロード テストで問題の検出が続行される場合は、システム パフォーマンス カウンタを詳しく調べて、スローダウンまたは障害の根本原因を特定する必要があります。 これは、負荷が予期せずパフォーマンスの問題を引き起こすため、ロード テストがストレス テストになる場合です。 もっと詳しく知りたいですか?LoadView プラットフォームの デモについては、チームにお問い合わせください 。 パフォーマンス エンジニアが、負荷とストレス テストのプロセス全体を説明します。 Web ページまたは Web アプリケーション シナリオのスクリプトの作成方法の説明から、テストの構成と起動まで、プロセス全体を通して、その過程で疑問を抱く可能性がある質問に答えます。
LoadView のチームは、お客様とお客様の開発チームが、負荷とストレス テストのプロセスと予算を最大限に活用できるようにサポートします。 使いやすいプラットフォームと役立つ専門家に支えられて、ロードテストとストレステストをそれぞれ実行するタイミングを理解することで、インテリジェントなテストプロセスをDevOps戦略に統合し、Webサイトや ウェブ アプリケーションのユーザーに結果をすばやく提供できます。
急速に変化するデジタル環境のほとんどのものと同様に、専門家の助けを活用することが重要です。 LoadView では、負荷テストとストレス テストのための業界をリードするプラットフォームの開発に全力で取り組んでいます。 私たちは、クライアントがロードテストで重要なこと、つまりWebサイトやアプリケーションの開発、およびサポートインフラストラクチャの開発に有意義な変化をもたらす洞察に変えることができる正確で実用的な結果に集中できるように支援します。
定期的な負荷テストとストレステストを行わないと、Webサイトとアプリケーションはパフォーマンスの低下や深刻なダウンタイムのリスクにさらされます。 Webサイトがクラッシュプルーフであると確信している場合でも、適切なテストは、あなたとあなたの開発チームが世界中のユーザーにさらに安心とより良いエクスペリエンスを提供できる改善を行うのに役立ちます。 オンラインの世界では、スピードが重要です。 LoadView を頼りになる読み込みおよびストレス テスト プラットフォームとして使用すると、ユーザーに可能な限り最高のエクスペリエンスを提供し、稼働時間を確保できます。 今すぐ無料の LoadView 試用版 にサインアップしてください。
クレジットカードはご利用になっていません。 コミットメントなし。 あなたが行くように支払う。