ロード テストを回避する任意の ウェブ アプリケーションは危険です。 なぜでしょうか。 プログラムが過度の負荷にさらされると、システム全体が膝の上に落ち、時間とリソースの無駄と潜在的に不幸なユーザーを提供する可能性があります。 そのため、ロード テストは、適用する必要があるパフォーマンス テストの重要な部分の 1 つです。 幸いにも、プロセスを容易にするさまざまな負荷テストツールがあります。 しかし、多くの開発者やテスターは、この仕事をするためにJMeterを使用することを好みます。 そこで、いくつかの負荷テストの例を参考にしてJMeterの詳細を知るために飛び込んでいきます。
ロードビューでJMeterロードテストの制限を克服
JMeterとは何ですか?
100% Java 言語、Apache JMeter、または JMeter を使用して開発された強力で、機能の多い負荷テスト ツールです。 このプログラムは、同時ユーザーを生成して、実際のテスト環境を作成して、ウェブ アプリケーションまたはモバイル アプリケーションのボトルネックを認識することで、動的リソースと静的リソースの両方をロードできます。 静的リソースと動的リソースについて説明する際、静的リソースは JavaScript や HTML などの言語やフレームワークになります。 動的リソースは、AJAX、Flex のようなフレームワークや言語である可能性があります。
しかし、JMeterはブラウザではないので、HTTPまたはプロトコルベースのテストのみを実行して実行できることを覚えておくことが重要です。 ブラウザ内のすべてのアクションをサポートするわけではなく、ブラウザとまったく同じように ウェブ ページやアプリケーションを表示することはできません。 さらに、JMeterは、ソースを分析した後に完全なレポートを提供し、結果は解釈のさまざまなモードを通じて調べることができます。 しかし、JMeterはJavaScriptをレンダリングしないので、結果に与えられるのは応答時間であり、実際のユーザーエクスペリエンスに関する詳細はユーザーの視点からは得られません。
ロード テストとは
ロード テストは、前述のように、さまざまな負荷 (ユーザー/トラフィック) で適用されたアプリケーションの動作を評価する方法です。 簡単に言えば、ロードテストは、20人のユーザーが一度にプラットフォームを使用しているときにプログラム(ウェブサイトの「abc.com」と仮定します)がどのように実行されるのかを理解するのに役立ちます。 同様に、ユーザー数が 20 から 100 に増加した場合のパフォーマンスの変化は何ですか。 何千人ものユーザーがいますか? ロード テストは、開発プロセスで発生したエラーを特定するために適用され、特定のソフトウェアのパフォーマンス低下や障害の原因となります。 これにより、開発者は間違いを修正して、すべてがスムーズに実行されるようにすることができます。 その反するに、ロード テストでは、正しい結果を得るために、プロフェッショナルで経験豊富なチームが必要になる場合があることを知っておくべきです。
5つのJメーター負荷試験ケース
プロセスを把握するのに役立つ5つの JMeter負荷テスト 例を示します。 それぞれの例には、理解を深めるための異なるアプリケーションが含まれています。 また、すべてのJMeter負荷試験には適切なテスト計画が必要です。 ワークステーションにJMeterをインストール済みであると仮定すると、これらの例から学び、アプリケーションを自分でテストすることができます。 ただし、事前の専門知識がない場合は、専門家の助けを借りることをお勧めします。 始めましょう。
例 1 – Google のロード テスト
最初の例では、100人のユーザーが予想される場合にJMeterを使用して Google.com のために行われた試験者の分析を見ようとしています。
テスト計画と結果
ステップ 1: スレッドグループの追加
JMeterを開き、「テスト計画」オプションを右クリックします。 [追加] と [スレッド] (ユーザー) にカーソルを合わせて 、[スレッド グループ] を選択します。 コントロール パネルに向かう場合は、’スレッド プロパティ’ を追加する必要があります。
テスト計画 > > スレッドの追加 > スレッド グループ
「スレッド数」に「100」と入力し、「ループカウント」を100、ランプアップ期間を100にします。 しかし、待って! 用語を覚えておいてください。 スレッドの数は、プラットフォームを使用しているユーザーの数を説明します (この場合、google.com)。 ループカウントは、テストを実行する回数を定義します。 そして、 ランプアップ期間 は、どの間隔の後に新しいユーザーを追加する必要があることを通知します。 したがって、この例は、100秒の遅延の後に含まれる100人のユーザーがいるときにJMeterを通して負荷テストを行うものです。
ステップ2:JMeterの要素を追加する
ここでは、テスト担当者がJMeter要素を決定しました。 したがって、スレッドグループを作成した後、「HTTP リクエストのデフォルト」オプションを選択する必要があります。 これを行うには、スレッドグループを右クリックし、「構成要素」にカーソルを合わせて、「HTTP リクエストのデフォルト」を選択します。 次に、サーバー名または IP アドレス (この場合は http://www.google.com)を追加する必要があります。
スレッド グループ > 構成要素 > HTTP 要求の既定値
その後、「スレッドグループ」を右クリックし、カーソルを「追加」にカーソルを合わせ、「サンプラー」にカーソルを合わせ、「HTTPリクエスト」をクリックします。 テストする特定のパスがある場合は、HTTP 要求コントロール パネルの [パス] フィールドに入力します。 たとえば、フィールドに「カレンダー」を入力すると、JMeterがGoogleサーバーへのURLリクエスト(http:www.google.com/カレンダー)を作成できます。
>サンプラー > HTTP リクエストの追加
しかし、この例では、テスト担当者はパス フィールドを空白のままにしており、情報は知識の構築に関する情報にすぎません。
ステップ 3: グラフの結果を追加する
完了したら、もう一度[追加]を選択し、「リスナー」にカーソルを合わせ、「グラフ結果」を選択して、グラフィックの形でテスト結果を受け取ります。
>リスナー > グラフの結果の追加
ステップ4:テストと結果の解釈
すべての手順を慎重に完了したら、ツールバーから「実行」をクリックしてプログラムのテストを開始します(Google)。 まもなく、リアルタイムでグラフを通してテスト結果が表示されます。 テストが終了すると、JMeterのインターフェースの下部に異なる色の統計情報が表示されます。 それぞれの色には意味があります。 例えば：
青: 送信されたサンプルの平均
ブラック: 送信されたサンプルの総数
緑: サーバーが取り組んだ要求 (トラフィック/ユーザー) の数を毎分表示するスループット率。
赤: 標準偏差
すべての例でスループット(緑)と偏差(赤)を分析する必要があることに注意してください。 なぜでしょうか。 これは、スループットは、負荷の大きい処理に関してサーバーの容量を表す最も重要なパラメータだからです。 したがって、スループットが高く、偏差が低いと、サーバのパフォーマンスが著しく向上します。
したがって、このJMeter負荷テストの例では、Googleのスループットは毎分1,491.193です。 これは、Google サーバーが 1,491.193 リクエスト/分に対応できることを意味します。 そして、偏差は577です。 したがって、Googleサーバーは模範的であり、最大の負荷を負担できることを実証しています。
例2 – Yahooのロードテスト
Googleの後、同様のテスト計画(100スレッド数、10のループカウント、100 ‘ランプアップ期間’)と最初の例で述べたのと同じ手順に従って、JMeterを介してYahooをロードテストしてみましょう。
全体の方法を経て、Yahooのために得られた結果は次のとおりです。
- スループt = 毎分 867.326
- 偏差 = 2689
これは、サーバが毎分867.326要求しか処理できないということを意味します。 また、偏差は非常に高い(2689)。 Yahooサーバーは、特にGoogleと比較する場合、過度のトラフィックに取り組むことはできません。 したがって、結果は、YahooのパフォーマンスがGoogleに比べて理想的ではないことを示しています。
例 3 – デモ PetStore のロード テスト
これはデモペットストアサイト(JPetstore)の例です。
テスト計画と結果
ステップ 1: スレッドグループの追加
最初のステップは例 1 に似ています。 そこで、JMeterで「テスト計画」を開き、「スレッドグループ」を選択します。
テスト計画 > > スレッドの追加 > スレッド グループ
次に、’スレッドプロパティ’に次の値を入力します。
- スレッド数 (ユーザー) = 20
- ランプアップ期間 (秒) = 120
- ループカウント = 「永遠」にチェック
ステップ2:JMeterの要素を追加する
[HTTP 要求の既定値] オプション (例 1 に示すように) をクリックし、サーバー名または IP アドレス(http://localhost:8080/actions/Catalog.action)を追加します。スレッド グループ > 構成要素 > HTTP 要求の既定値
手記: JPetstore はデモ サイトであり、テスト環境でテスト担当者が利用しているため、パーソナル サーバー (localhost) で利用できるため、インターネット上でアクセスできません。 この例では、パスは使用されません。 ただし、JMeter ロード テストを実行するアドレスは追加できます。 例えば www.google.com
。
ステップ 3: グラフの結果を追加する
「リスナー」に移動して「グラフ結果」を選択し、ビジュアルの結果を取得します。
>スレッドグループ > グラフの結果を追加
ステップ4:テストと結果の解釈
この場合、スループットは 1 分あたり 89.871、偏差は 142 (スループットより大きい) です。 したがって、このグラフは、JPetstore が負荷を処理できないことを明確にしています。
例4 – JMeterアパッチの負荷テスト
この例は、解釈のためのグラフ結果を使用してJMeter Apache(jmeter.apachi.org)をロードテストするために作られています。
テスト計画と結果
ステップ 1: スレッドグループの追加
前の例と同様に、「テスト計画」を開き、「スレッドグループ」をクリックします。
テスト計画 > > スレッドの追加 > スレッド グループ
[スレッド プロパティ] に次の値を入力します。- スレッド数 (ユーザー) = 100
- ランプアップ期間 (秒) = 100
- ループ数 = 20
ステップ2:JMeterの要素を追加する
ここで、前の例に示したとおりに HTTP リクエストのデフォルトを作成します。
スレッド グループ > 構成要素 > HTTP 要求の既定値
この場合、テスト担当者は ‘Path’ を使用してダウンロード ページの要求 (download_jmeter) を作成しています。 したがって、パス フィールドに要求を入力します。
>サンプラー > HTTP リクエストの追加
ステップ 3: グラフの結果を追加する
「リスナー」にカーソルを合わせると、ビジュアルの結果を得るために「グラフ結果」を選択します。
>スレッドグループ > グラフの結果を追加
ステップ4:テストと結果の解釈
このシナリオでは、偏差は 195、スループットは 1,136.719 (偏差より大きい) です。 これは、ダウンロードページが毎分1,136.719の負荷(要求/ユーザー)を管理できることを意味し、かなり印象的です。
例5 – Eコマース ウェブ サイトのロードテスト
電子商取引アプリケーションの負荷テストについては、ブラックフライデーなどの季節的な販売と同様に、これらのイベントがより多くの顧客を引き付けるため、定期的に準備する必要があります。 まだ開発中の電子商取引プラットフォームがあることを考えると、ユニークなユーザーを設計してJMeterロードテストを実行する必要があります。
テスト計画と結果
ステップ1 – 現実的に漏斗を設定する
E コマース サイトの場合、通常、顧客はホームページにアクセスし、製品を探し、カートに追加して、チェックアウトします。 この例では、ソフトウェアに注意を払う場合は、スループットを設定する必要がある「スループットコントローラ」オプションと、インターフェイスの左側にある「スレッドグループ」ドロップダウンパネルに表示される「Funnel」オプションがあります。 これらのオプションは、ユーザー比率を定義するのに役立ちます。 したがって、両方のオプションに同じ値を入力する必要があります。
この例では、テスト担当者は 100% の仮想ユーザーをホーム ページにアクセスし、ユーザーの 90% は特定の製品を検索します。 90%のうち60%が商品をカートに追加する可能性が高く、購入プロセスをチェックアウトして完了するユーザーはわずか35%です。 テストは想定に基づいているため、スループットと漏斗は 90% に設定されます。
ステップ 2: 待ち時間の追加
現実的な結果を得るために、JMeterでは、実際のユーザーが製品を選択するために必要な時間を定義する「思考時間」を追加することができます。 これらは非公式に pause と呼ばれ、結果が現実に近いようにテスト ケースに含める必要があります。
1 秒または 2 秒の遅延は非現実的なので追加しないでください。 そのため、この例では、テスト担当者はランダム遅延に対して「スレッド遅延プロパティ」に750ミリ秒を設定し、定数遅延を200ミリ秒に設定しています。 すべては、コントロールパネルから「均一ランダムタイマー」を使用して行われます。
ステップ 3: スレッドグループパラメータの設定
例 1 と同様に、「スレッドグループ」オプションをクリックして、「スレッド数」「ランプアップ期間」「ループカウント」を含める必要があります。 この例のプロパティを次に示します。
- スレッド数 (ユーザー): 100
- ランプアップ期間 (秒): 1
- ループ数: 50
ステップ 3: 一意の仮想ユーザーの作成
このステップは非常に重要です。 一意の名前、ユーザー ID、パスワード、連絡先の詳細、およびチェックアウト時に必要なすべての情報を持つユーザーのリストを作成する必要があります。 また、仮想ユーザーが実際のユーザーのように動作できるように、製品キーワードをリストに追加する必要があります。 また、リストに含める情報がウェブサイトに存在していることを確認してください。 プラットフォームのコンテンツがゼロの場合、JMeterの負荷テスト結果は意味をなさないでしょう。
リストが完成したら、CSVファイルとして保存し、ロードテスト中にJMeterにインポートします。
ステップ 4: グラフ結果を追加する
結果をグラフィカルな表現で表示するには、「グラフ結果」を追加する必要があります。 例 1 の 「ステップ 3」に従ってグラフの結果を追加できます。
ステップ5:テストと結果の解釈
テストの実行後、テスト レポートが表示されます。
上記のビジュアル表現では、スループットが 64.186/分であるのに対し、偏差は 122 (スループットより大きい) であることを明らかにします。 これは、電子商取引のウェブサイトが1分で100人のユーザーを扱うことができず、予想よりも少ない負荷にしか取り組むことができないという意味です。 したがって、ウェブ サイトがロード テストをバイパスすることを確認するエラーを修正する必要があります。
手記: CPUの電力、テスト環境、インターネット速度など、いくつかの要因によって、JMeterの負荷テストは異なる結果を生み出すことができます。 そのため、専門家は洗練されたリソースを持っているので、最終的に真の結果を明らかにするので、テストを処理することをお勧めします。
ポインター
上記のJMeterロードテストの例は、JMeterの2つの異なるバージョンを使用して終了しているので、インストールされているバージョンで異なる用語を見つけた場合は慌てないでください。 上記の結果はすべて「グラフ結果」で解釈されます。 それにもかかわらず、結果を表現するために使用できる他の「リスナー」は、次のように。
- レポートの集計
- 集計グラフ
- 結果を表に表示
- 結果をツリーとして表示
- 概要結果の生成
結論: 5つのJMeter負荷試験例
JMeterは、リアルタイムで処理できる同時ユーザー数を知るために、ウェブ アプリケーションの負荷テストに使用されるツールです。 テストは、負荷の容量を識別するために、GoogleとYahooを含む5つの異なるプログラムに適用されます。 さらに、各例の結果は「グラフ結果」リスナーを使用して解釈されます。 しかし、これは通常、正しい結果を保証するために専門的な監督を必要とする複雑なプロセスであり、後でアプリケーションのボトルネックを修正するのに役立ちます。
そのため、LoadViewは信頼性の高い結果を保証できる信頼できるロード テスト プラットフォームであり、ハードウェア、時間、労力に多大な投資を必要としません。今日の LoadView 無料試用版を試してみてください。 ご質問がある場合は、24時間365日 当社のエンジニアに連絡 して、お問い合わせに回答し、ロードテストの問題をすべて解決してください。
最後に、ライブ実稼働環境で ウェブ ページと ウェブ アプリケーションの継続的な監視を組み込むことを確認します。 ウェブ アプリケーションと ウェブ ページは、さまざまなリソースに依存しています。 問題が発生した瞬間に、チームとチームに通知されていることを確認します。 Dotcom-Monitor プラットフォームでは、エラーやパフォーマンスの問題が発生した場合に監視デバイスとアラートを迅速に設定するために必要なソリューションと機能を使用して、チームが問題のトラブルシューティングを迅速に行い、追加のユーザーに影響を与える前に修正できます。 詳しくは、ドットコムモニターの 監視ソリューション をご覧ください。