JMeterのヒント

JMeterは、負荷テスト用の人気のあるオープンソースツールであり、スレッドグループ、タイマー、HTTPサンプラー要素などの多くの便利なモデリング機能を備えています。この記事は、JMeterユーザーズマニュアルを補足し、JMeterモデリング要素のいくつかを使用して品質テストスクリプトを開発するためのガイドラインを提供します。

この記事では、より大きなコンテキストでの重要な問題、つまり正確な応答時間要件の指定とテスト結果の検証についても説明します。具体的には、厳密な統計手法である信頼区間分析が適用されます。

読者はJMeterの基本を知っていると思いますのでご注意ください。この記事の例は、JMeter2.0.3に基づいています。

スレッドグループの立ち上げ期間を決定する

JMeterスクリプトの最初の要素はスレッドグループなので、最初に確認しましょう。図1に示すように、スレッドグループ要素には次のパラメーターが含まれています。

  • スレッドの数。
  • 立ち上げ期間。
  • テストを実行する回数。
  • 開始時に、テストをすぐに実行するか、スケジュールされた時間まで待機するか。後者の場合、スレッドグループ要素には開始時刻と終了時刻も含める必要があります。

各スレッドは、他のスレッドとは独立してテスト計画を実行します。したがって、スレッドグループは、同時ユーザーをモデル化するために使用されます。JMeterを実行しているクライアントマシンに重い負荷をモデル化するのに十分な計算能力がない場合、JMeterの分散テスト機能を使用すると、単一のJMeterコンソールから複数のリモートJMeterエンジンを制御できます。

ランプアップ期間は、スレッドの総数を作成するための時間をJMeterに通知します。デフォルト値は0です。ランプアップ期間が指定されていない場合、つまりランプアップ期間がゼロの場合、JMeterはすべてのスレッドをすぐに作成します。ランプアップ期間がT秒に設定されていて、スレッドの総数がNの場合、JMeterはT / N秒ごとにスレッドを作成します。

スレッドグループのパラメータのほとんどは自明ですが、適切な数が常に明らかであるとは限らないため、立ち上げ期間は少し奇妙です。一つには、スレッドの数が多い場合、ランプアップ期間をゼロにするべきではありません。負荷テストの開始時に、ランプアップ期間がゼロの場合、JMeterはすべてのスレッドを一度に作成し、すぐに要求を送信します。これにより、サーバーが飽和状態になる可能性があり、さらに重要なことに、負荷がだまされて増加します。つまり、平均ヒット率が高いためではなく、すべてのスレッドの最初の要求を同時に送信するためにサーバーが過負荷になり、異常な初期ピークヒット率が発生する可能性があります。この効果は、JMeter AggregateReportリスナーで確認できます。

したがって、この異常は望ましくないため、妥当なランプアップ期間を決定するための経験則は、初期ヒット率を平均ヒット率に近づけることです。もちろん、妥当な数を見つける前に、テスト計画を1回実行する必要がある場合があります。

同様に、ピーク負荷が過小評価される可能性があるため、大きなランプアップ期間も適切ではありません。つまり、一部のスレッドは開始されていない可能性がありますが、一部の初期スレッドはすでに終了しています。

では、ランプアップ期間が小さすぎたり大きすぎたりしないことをどのように確認しますか?まず、平均ヒット率を推測し、次にスレッド数を推測されたヒット率で割って初期ランプアップ期間を計算します。たとえば、スレッド数が100で、推定ヒット率が1秒あたり10ヒットの場合、推定理想的なランプアップ期間は100/10 = 10秒です。どのようにして推定ヒット率を考え出しますか?簡単な方法はありません。最初にテストスクリプトを1回実行するだけです。

次に、図2に示す集計レポートリスナーをテスト計画に追加します。これには、個々のリクエスト(JMeterサンプラー)の平均ヒット率が含まれています。最初のサンプラー(HTTPリクエストなど)のヒット率は、ランプアップ期間とスレッド数に密接に関連しています。テスト計画の最初のサンプラーのヒット率が他のすべてのサンプラーの平均ヒット率に近くなるように、ランプアップ期間を調整します。

3番目に、JMeterログ(JMeter_Home_Directory / binにあります)で、終了する最初のスレッドが実際に最後のスレッドの開始後に終了することを確認します。2つの間の時間差は可能な限り離れている必要があります。

要約すると、適切な立ち上げ時間の決定は、次の2つのルールによって決まります。

  • 最初のサンプラーのヒット率は、他のサンプラーの平均ヒット率に近く、それによって小さなランプアップ期間を防ぐ必要があります
  • 終了する最初のスレッドは、最後のスレッドが開始した後、できれば可能な限り離れて実際に終了するため、大きなランプアップ期間が防止されます。

2つのルールが互いに競合する場合があります。つまり、両方のルールに合格する適切な立ち上げ期間を見つけることができません。些細なテスト計画では通常、この問題が発生します。このような計画では、各スレッドに十分なサンプラーがないためです。したがって、テスト計画が短すぎて、スレッドがすぐに作業を終了します。

ユーザーの思考時間、タイマー、プロキシサーバー

負荷テストで考慮すべき重要な要素は、思考時間、つまり連続する要求間の一時停止です。さまざまな状況で遅延が発生します。ユーザーは、コンテンツを読んだり、フォームに入力したり、正しいリンクを検索したりするのに時間が必要です。思考時間を適切に考慮しないと、テスト結果に深刻な偏りが生じることがよくあります。たとえば、推定されたスケーラビリティ、つまりシステムが維持できる最大負荷(同時ユーザー)は低く表示されます。

JMeterは、思考時間をモデル化するためのタイマー要素のセットを提供しますが、疑問が残ります。適切な思考時間をどのように決定するのですか?幸いなことに、JMeterは良い答えを提供します:JMeterHTTPプロキシサーバー要素。

プロキシサーバーは、通常のブラウザー(FireFoxやInternet Explorerなど)でWebアプリケーションを参照している間のアクションを記録します。さらに、JMeterは、アクションを記録するときにテスト計画を作成します。この機能は、いくつかの目的に非常に便利です。

  • HTTPリクエスト、特に面倒なフォームパラメータを手動で作成する必要はありません。(ただし、英語以外のパラメーターは正しく機能しない場合があります。)JMeterは、非表示フィールドを含め、自動生成された要求にすべてを記録します。
  • 生成されたテスト計画では、JMeterには、User-Agent(Mozilla / 4.0など)やAcceptLanguage(zh-tw、en-us; q = 0.7、zh-など)など、ブラウザーで生成されたすべてのHTTPヘッダーが含まれています。 cn; q = 0.3)。
  • JMeterは、選択したタイマーを作成できます。遅延時間は、記録期間中の実際の遅延に応じて設定されます。

記録機能を使用してJMeterを構成する方法を見てみましょう。JMeterコンソールで、WorkBench要素を右クリックし、HTTPプロキシサーバー要素を追加します。ここでの構成は記録用であり、実行可能なテスト計画用ではないため、テスト計画要素ではなくWorkBench要素を右クリックすることに注意してください。HTTPプロキシサーバー要素の目的は、すべてのリクエストがJMeterを通過するようにブラウザーのプロキシサーバーを構成することです。

図3に示すように、HTTPプロキシサーバー要素にはいくつかのフィールドを構成する必要があります。

  • ポート:プロキシサーバーが使用するリスニングポート。
  • ターゲットコントローラー:プロキシが生成されたサンプルを保存するコントローラー。デフォルトでは、JMeterは現在のテスト計画で記録コントローラーを探し、そこにサンプルを保存します。または、メニューにリストされている任意のコントローラー要素を選択することもできます。通常、デフォルトは問題ありません。
  • グループ化:テスト計画で生成された要素をどのようにグループ化するか。いくつかのオプションが利用可能ですが、最も賢明なオプションはおそらく「各グループの最初のサンプラーのみを保存する」です。そうでない場合、画像やJavaScriptなどのページに埋め込まれたURLも記録されます。ただし、デフォルトの「サンプルをグループ化しない」オプションを試して、JMeterがテスト計画で正確に何を作成するかを確認することをお勧めします。
  • インクルードするパターン:パターンを除外するためにあなたには、いくつかの不要な要求をフィルタリングヘルプを。

[開始]ボタンをクリックすると、プロキシサーバーが起動し、受信したHTTP要求の記録を開始します。もちろん、[スタート]をクリックする前に、ブラウザのプロキシサーバー設定を構成する必要があります。

HTTPプロキシサーバー要素の子としてタイマーを追加できます。これにより、JMeterは、生成するHTTP要求の子としてタイマーを自動的に追加するように指示されます。JMeterは、実際の時間遅延をTと呼ばれるJMeter変数に自動的に格納するため、ガウスランダムタイマーをHTTPプロキシサーバー要素に追加する場合は、図4に示すように、[定数遅延]フィールドに$ {T}と入力する必要があります。あなたに多くの時間を節約するもう一つの便利な機能。

タイマーにより、影響を受けるサンプラーが遅延することに注意してください。つまり、影響を受けるサンプリング要求は、最後に受信した応答から指定された遅延時間が経過するまで送信されません。したがって、最初のサンプラーは通常タイマーを必要としないため、最初のサンプラーで生成されたタイマーを手動で削除する必要があります。

HTTPプロキシサーバーを起動する前に、テスト計画にスレッドグループを追加してから、スレッドグループに、生成された要素が格納される記録コントローラーを追加する必要があります。それ以外の場合、これらの要素はWorkBenchに直接追加されます。さらに、HTTPリクエストのデフォルト要素(構成要素)をレコーディングコントローラーに追加して、JMeterがHTTPリクエストのデフォルトで指定されたフィールドを空白のままにすることが重要です。

記録後、HTTPプロキシサーバーを停止します。Recording Controller要素を右クリックして、記録された要素を別のファイルに保存し、後で取得できるようにします。ブラウザのプロキシサーバー設定を再開することを忘れないでください。

応答時間の要件を指定し、テスト結果を検証します

JMeterとは直接関係ありませんが、応答時間要件の指定とテスト結果の検証は、負荷テストの2つの重要なタスクであり、JMeterはそれらを接続するブリッジです。

Webアプリケーションのコンテキストでは、応答時間とは、要求の送信から結果のHTMLの受信までに経過した時間を指します。技術的には、応答時間にはブラウザがHTMLページをレンダリングする時間を含める必要がありますが、ブラウザは通常、ページを1つずつ表示するため、知覚される応答時間が短くなります。さらに、通常、負荷テストツールは、レンダリング時間を考慮せずに応答時間を計算します。したがって、パフォーマンステストの実用的な目的のために、上記の定義を採用します。疑わしい場合は、測定された応答時間に定数、たとえば0.5秒を追加します。

応答時間の基準を決定するためのよく知られたルールのセットがあります。

  • ユーザーは0.1秒未満の遅延に気づきません
  • 1秒未満の遅延は、ユーザーの思考の流れを妨げることはありませんが、ある程度の遅延が見られます。
  • 遅延が10秒未満の場合でも、ユーザーは応答を待ちます
  • 10秒後、ユーザーはフォーカスを失い、何か他のことを始めます

これらのしきい値はよく知られており、人間の認知特性に直接関連しているため、変更されません。これらのルールに従って応答時間の要件を設定する必要がありますが、特定のアプリケーションに合わせて調整する必要もあります。たとえば、Amazon.comのホームページは上記のルールを順守していますが、よりスタイリッシュな外観を好むため、応答時間が少し犠牲になります。

一見すると、応答時間の要件を指定する方法は2つあるように見えます。

  • 平均応答時間
  • 絶対応答時間; つまり、すべての応答の応答時間はしきい値を下回っている必要があります

平均応答時間要件の指定は簡単ですが、この要件がデータの変動を考慮に入れていないという事実は気がかりです。サンプルの20%の応答時間が平均の3倍を超える場合はどうなりますか?JMeterは、グラフ結果リスナーで平均応答時間と標準偏差を計算することに注意してください。

一方、絶対応答時間の要件は非常に厳しく、統計的に実用的ではありません。サンプルの0.5%だけがテストに合格しなかった場合はどうなりますか?繰り返しますが、これはサンプリングの変動に関連しています。幸いなことに、厳密な統計手法では、サンプリングの変動、つまり信頼区間分析が考慮されます。

先に進む前に、基本的な統計を確認しましょう。

中心極限定理

中心極限定理は、母集団分布に平均μと標準偏差σがある場合、nが十分に大きい(> 30)場合、サンプリング平均のサンプリング分布はほぼ正規分布であり、平均μ平均=μと標準偏差σであると述べています。平均=σ/√n。

サンプリング平均の分布は正常であることに注意しください。サンプリング自体の分布は必ずしも正常ではありません。つまり、テストスクリプトを何度も実行すると、結果の平均応答時間の分布は正常になります。

以下の図5と6は、2つの正規分布を示しています。私たちの文脈では、横軸は応答時間のサンプリング平均であり、母集団の平均が原点になるようにシフトされています。図5は、90%の時間、サンプリング平均が±Zσの間隔内にあることを示しています。ここで、Z = 1.645、σは標準偏差です。図6は、Z = 2.576の99パーセントの場合を示しています。与えられた確率、たとえば90パーセントに対して、対応するZ値を正規曲線で検索できます。その逆も可能です。