負荷テストとストレステスト

負荷とストレステストの比較

ロード テストは、定義上、予想される負荷の下でシステムのパフォーマンスを測定します。

これに対して、ストレス テストは、ブレークポイントを見つけるためにシステムをオーバーロードします。

相違点を調べる:

負荷とストレス テスト

 

ストレス パフォーマンス テスト ロード テストは、システムに対して指定された数の要求を実行して、同時要求の特定のレベルでシステムの機能をテストするための計画テストです。 ロード テストでは、ウェブ システムが予想されるトラフィック量を処理できるため、ボリューム テストと呼ばれることがあります。 ロード テストの目的は、システムが期待されるボリュームを、許容可能なパフォーマンス低下まで最小限に抑え、処理できることを証明することです。 許容可能なパフォーマンス低下のしきい値は、ユーザーがサイトから跳ね返らないように、エンド ユーザーに許容可能と見なされる値としてテスターによって定義される必要があります。

ストレス テストは、パフォーマンスが低下した時点を過ぎてシステム上の同時要求の数を増やすために設計されたテストです。 ロード テスト ( または API テスト) が同時ユーザー数でピークに達した場合、基本的なストレス テストは、リソースが過負荷になるまでシステムの負荷を増加し続けます。 これにより、システムが障害を起こす可能性のある状態にまでシステムが押し込まれ、システムがどのように処理されるか、およびシステムが正常な回復を実行できるかどうかを確認できます。

ロード テストとストレス テストのこれらの定義の中で、それらが互いに完全に独立しているわけではないことが分かります。 多くの場合、ロード テストの上限を実行すると、有効なストレス テストが実行され、システムが使用可能なリソースの制限を超えてプッシュされる場合があります。 この時点で、ストレス テストの実行時に通常見られるエラーと同じ、ロード テストの失敗が表示され始める場合があります。

ロード テストまたはストレス テストを選択する場合

 

ロード テストとストレス テストの違いの 1 つは、実際のユーザー トラフィックをシミュレートするために、ロード テストに一時停止を挿入する可能性があるという点です。 ストレス テストを使用すると、できるだけ多くの同時ユーザーを実行して、ストレス テスト用に過剰なトラフィックを生成できます。

ロード テストの目的は、ストレス テストの目的とは大きく異なります。 ロード テストは、ウェブ サイトまたは ウェブ アプリケーションが特定の数のユーザーを一度に処理できることを確認するために実行されます。 ロード テストは、キャパシティ プランニングのプロセスで頻繁に使用され、システムが指定されたレベルの同時トラフィックに対する拡張を確実に処理できるようにします。

ストレス テストは、システムを目的の容量を超えて、速度の低下を開始し、システムのボトルネックを特定し、発生する可能性のある障害点を明示するために、システムを具体的にプッシュするために使用されます。

負荷・ストレステストに一般的に使用されます。
ベースライン パフォーマンス メトリックの確立

ロード テストは通常、インフラストラクチャでサポートされるとわかっている同時ユーザーの数をテスト システムが開始する一連の手順として実行されます。 これにより、テスト全体で同時ユーザー数が増加すると、参照するパフォーマンス・データのベースライン・セットが確立されます。 このベースライン テストは、パフォーマンス テストと呼ばれることもあります。 パフォーマンス テストは、平均接続速度、平均待機時間、固定サイズ以上のファイルをダウンロードする平均時間など、いくつかの異なるベンチマークを決定するのに役立ちます。

ベースライン パフォーマンス値がわかっている場合、サンプル期間中に実際にサイトを訪問することが予想される数にユーザー数が増加します。 多くの場合、テストは、システムが新しい負荷レベルで安定した後、ウェブサイトの安定性を確認するために、数分間、その静的な数のユーザーで実行されます。

仮想ユーザー

負荷テストとストレス テストの間にベースライン パフォーマンス メトリックを確立する場合の 1 つの違いは、ベースラインとピーク パフォーマンスの違いが、ピーク負荷を処理するための適切なシステムがあるかどうかを判断するのに役立ちます。

ウェブ アプリのボトルネックを特定するための負荷テストまたはストレス テスト

ウェブ ベースのアプリケーションは、通常、ブラウザで実行され、非同期的な性質のために適切にプログラムされると、数百または数千の同時ユーザーを処理する場合があります。 システムの容量内で予想される負荷を生成する場合、アプリケーションの応答時間は生成されたガイドライン内に留まる必要があります。 これらの制限を超えてシステムをプッシュすると、ストレステストの領域に移動し、意図的にシステムに負担をかけ、故障したコンポーネントを特定します(これは JMeterなどのオープンソースツールで行われることが多いです)。 したがって、ボトルネックを特定するために実行されるテストは、通常、ストレス テストと見なされます ( API テストや API 監視とは異なります ) 。

スラレポート
サービス レベル アグリーメント (SLA) を確立するためのロード テスト

 

ロード テストは、予想されるユーザー 負荷の平均応答時間を理解するために、運用環境で実行するのが最適です。 これらの平均応答時間は、許容可能な SLA のベースラインになります。 ここから、顧客に期待されるパフォーマンスの観点から、SLA の下で受け入れられないと考えられる追加のしきい値を決定するのは、ユーザーの責任です。

容量計画のロード テスト

ウェブ アプリケーションの負荷を増加させることにより、今後のユーザー負荷が高くなるアプリケーションのパフォーマンスを予測できます。 アプリケーションが SLA パラメータ内で応答する場合、通常、このようなテストは、キャパシティ プランニングの成功したコンポーネントと見なされます。 テスト中に記録されたパフォーマンス メトリックが望ましいパラメーターの外にある場合、システムを使用可能な容量を超えてシステムをプッシュすると、ロード テストがストレス テストになる可能性があります。

ストレス テスト ウェブ アプリ インフラストラクチャ

インフラストラクチャ内の各コンポーネントが失敗するポイントを特定することは、スケーラブルな ウェブ アプリケーションを維持するうえで重要な部分です。 効果的なストレス テストを使用すると、一連の異なるテストを使用して各コンポーネントを分離し、そのコンポーネントの障害発生点を特定できます。 このようなテストには、次のようなものがあります。

  • 特定の地域へのすべてのトラフィックを分離する。
  • 使用可能なディスク領域を人為的に制限する。
  • 1 つの特に大きな GET 要求を繰り返し送信します。
  • データ接続の最大数を制限する。
  • 大きなイメージ ファイルをダウンロードしています。
  • データベースに大量に書き込む強烈な POST を繰り返し送信する。

各テストは、インフラストラクチャの特定のコンポーネントにストレスを与え、障害のポイント、障害率、およびシステム容量の上限を特定するように設計されています。 ストレステストは、ウイルスマーケティング、国際的なニュース認識、ブラックフライデーなどの重いオンラインショッピングの日などから短い激しい負荷の間にボトルネックを特定するのに役立ちます。

負荷テストとストレステストの違い

ビューの概要を読み込む

ストレス テストは通常、システムの 1 つの部分または別の部分を最大限に引き出し、最終的に速度低下を引き起こし、クラッシュまたは応答を停止します。 テスト中に最初に問題が発生するコンポーネントを決定することが重要です。 このため、ストレス テストを実行する際に監視する必要があるコンポーネントがいくつかあります。 アプリケーション、ソフトウェア、または環境/システムで使用されているテクノロジによって、ストレス テストで測定するメトリックは異なる可能性があることは注目に値します。 ただし、以下のリストは

  • 応答時間: 要求が送信された後に応答を受信するのにかかる時間。 これは、ユーザーが認識する応答時間を測定する場合に特に重要です。
  • ハードウェアの制約: これには、CPU 使用率、RAM、ディスク I/O の監視が含まれます。 応答時間が遅れたり遅くなったりすると、これらのハードウェア・コンポーネントが潜在的な原因となる可能性があります。
  • スループット: テスト期間中に送信/受信されるデータの量は、帯域幅レベルに基づいて行われます。
  • データベースの読み取りと書き込み アプリケーションで複数のシステムを使用している場合、ストレス テストによって、どのシステムまたはユニットがボトルネックになっているかを示すことができます。
  • データベース接続を開く: 大規模なデータベースは、パフォーマンスに深刻な影響を与え、応答時間が遅くなる可能性があります。
  • サードパーティコンテンツ: ウェブ ページとアプリケーションは、多くのサードパーティ製コンポーネントに依存しています。 ストレス テストを行うと、ページやアプリケーションのパフォーマンスに影響を与える可能性のあるテストが示されます。

サーバー側に適切な監視システムが配置されていない場合、Dotcom-Monitor プラットフォームは、エンドツーエンドのサーバー パフォーマンスを完全に 監視するためのパフォーマンス カウンター監視ソリューション を提供します。 これらのパフォーマンス カウンタは、Windows、Linux、または SNMP のパフォーマンス カウンタを監視するために、サーバーに直接インストールされます。 また、デバイスやサーバーからカスタム パフォーマンス カウンタを監視するソリューションもあります。 パフォーマンス カウンタの監視の詳細については、パフォーマンス カウンター監視ソリューションのページを参照してください。

これらの項目に関する問題は、次のように表示されます。

  • 最初のパケット応答が遅い。
  • GET/POST 要求と応答の間の長い遅延。
  • 通常のページ読み込み時間よりも長い。
  • ウェブ ​ページの読み込みがタイムアウトしました。
  • サーバー エラー コードが返されました。

ロード テストでは、これらの同じ問題が最初に検出される場合がありますが、ロード テストの背後にある考え方は、通常、システムが定期的に処理できる必要がある予想される負荷をシミュレートすることです。 負荷の増加にリソースを割り当てている間にシステムが一時的に減速する場合もありますが、ほとんどの場合、システムは最初の割り当てから回復し、ロード テストの下で通常のパフォーマンスを再開できる必要があります。

ロード テストで問題の検出が続行される場合は、システム パフォーマンス カウンタを詳しく調べて、スローダウンまたは障害の根本原因を特定する必要があります。 これは、ロード テストが本質的にストレス テストになる場合に、負荷が予期せずパフォーマンスの問題を引き起こす場合です。LoadView プラットフォーム のデモについては、チームにお問い合わせください 。 パフォーマンス エンジニアが、負荷とストレス テストのプロセス全体を説明します。 ウェブ ページまたは ウェブ アプリケーション シナリオのスクリプトの作成方法の説明から、テストの構成と起動まで、プロセス全体を通して、その過程で疑問を抱く可能性があります。

今日の負荷またはストレス テストを実行します。

クレジットカードはご利用になっていません。 コミットメントなし。 あなたが行くように支払う。