2012-04-25 10 views
8

実行時にJMeterテストプランのスレッド数を変更したいとします。実行時にJMeterのテストプランのスレッド数を変更する

私は私の問題をGoogleで探究し、JMeterプラグインを使用するための提案されたソリューションを見つけました。しかし、このソリューションでは、テストプランを実行する前にスレッドグループのスケジュールを設定する必要があります。これは必要ありません。また、プロパティを変更するanother potential solutionが見つかりましたが、実行時のテスト計画の動作には影響しません。

最終的には、スレッドグループに指定されたスレッド番号を変更して、現在実行中のテスト計画のスレッド数を即座に増減させることを試みています。

これは可能ですか?

+0

要件を記述することはできますか?あなたは動的に多数のユーザースレッドを操作して、正確に何を達成しようとしていますか?あなたのテストの目標は何ですか? –

+0

web-appの負荷を増減する動的な数値。私はjmeterプラグインを介してそれを行うことができますが、私は事前にスレッドを定義し、私がしたくない時間を待つ必要があります。 –

+0

私はそれを得るが、なぜですか?待機する必要はありません。プラグインの究極のスレッド・グループまたはステッピング・スレッド・グループを使用して、スレッドを任意の方法でスケジュールできます。数秒で何百ものランプを立ち上げることができます。私はそのような要求を聞いたことがないし、誰かがなぜそれを必要としているのだろうと思っていたので私は尋ねています。 –

答えて

3

短い答えは:いいえ、実行時にスレッドの数を動的に変更することはできません。各スレッドカウント値は、テスト計画が最初にコンパイルされた時点で一度だけ読み込まれ、この時点以降に再度解決されないため、固定されたままです。

6

IMHOは、適切なパフォーマンステストを行うときに本当のメリットがないファンシーな機能です。 関連するテスト出力(レポート)を生成するには、repeatabilityが必要であり、明確に定義されたテスト方法とシナリオが必要です。アプリケーション/サーバー/インフラストラクチャの変更の影響を比較するには、再現性が必要です。我々は最初の場所でのパフォーマンステストを行う理由です私たちのサイト

のユーザーを予測することはできません

によって

あなたは何を意味しています。私たちのアプリケーション/インフラストラクチャーの制限は何かを知るために。
I.生成できる最も重要なメトリックは、並列ユーザーの数が変化したときのアプリケーションの応答時間の変化です。しかし、実行時に不規則に変化することはありません。

jMeter plugins' Ultimate thread groupとすれば、想像を絶するシナリオをカバーできます。

+0

mbonaci。あなたが言っていることは正しいです。しかし、私はそこには、LoadUIが提供するように利用可能な機能があることを知りたいですか? JMeterはLoadUIよりも多くの機能を提供するので、私はもっと興味があります。 –

+0

繰り返し可能なテストに役立つ範囲で値を試して遊ぶことができれば便利なことがあります。究極のスレッドグループとステッピングスレッドグループのために、私は時間をかけてさまざまな値を試していました。ユースケースを持っていないという理由だけで、ユースケースがないというわけではありません。 – CharlieS

+0

あなたが追跡している指標は何ですか?私はまだあなたがその機能を必要としていた理由を理解していません。あなたのユースケースを詳しく教えてください。 –

1

起動スレッドで設定した変数に基づいて変更できます。下記参照。スレッドグループが起動した後

In Jmeter how do I set a variable number of threads using a beanshell sampler variable?

しかし、あなたはそれを変更することはできません。この機能が役に立たないと言った人には私は同意しない。負荷テストには多くのタイプがあり、すべてのユーザーがその期間実行しているわけではありません。 - 同じユーザー数は全体の時間を実行します(おそらく 短いランプアップ期間付き)

    • 耐久試験:ここでは、私は仕事銀行で行い、企業の負荷テストのわずか2例の種類があります点試験を破る - アプリケーションブレークまで漸増
    • スパイクテストユーザーの数を立ち上げ - ユーザーの大多数のユーザー数が一定で実行が、散発的に
      スローを

    ブレークポイントテストは、アプリケーションが破損するまでユーザーの数を増加させます(アプリケーションのスケーリングの可能性を確認することが重要です)。スレッドグループ「ランプアップ期間」プロパティを使用してソートすることができます。ランプアップ時間を1000に設定し、スレッド数を100に設定すると、10秒ごとに1つのスレッドが追加されます。

    スパイクテストはデュレーションテストと似ていますが、ある間隔では多数のユーザーがログインします。これはピーク時にアプリケーションの応答時間を測定したり、突然大量のユーザー(非常に実際のシナリオ)。

    Jmeterがエンタープライズ負荷テストに必要なすべての負荷テストシナリオを処理しないことがわかりました。私の考えの周りの1つの作業は、すべてのスレッドを開始するだけですが、それらのいくつかを眠らせる方法を見つけることです。だから、スレッド数を1000に設定することもできますが、何とか980をスリープさせるか何もしません。次に、time_in_seconds%5 == 0(5分ごと)のときに、他のスレッドを実行させることができます - スパイクテストをシミュレートします。アイデアは、スレッドを1000にハードコードすることができ、常に1000のスレッドを実行することです - しかし、それらはすべて、常に何かをしている必要はありません。

    (つまりあなたはおそらく方法を見つけることができますが、あなたは創造的な取得する必要がある)

    アップデート: 私は、テストの種類を可能にするこのプラグインを見つけました。まだそれを試みたが、有望に見えるしていない: http://jmeter-plugins.org/wiki/ThroughputShapingTimer/

  • 0
    あなたが設定/コマンドラインオプションを使用して、実行時にスレッドの数を変更することができ

    ...

    あなたはユーザパラメータへの関数呼び出し、変数の参照を使用することができます(これは関数でも可能です)、またはテストの早い段階で関数によって設定された変数への変数参照。それを行う方法は複数あります。

    テストプランのスレッド数を変えたいとします。適切なプロパティー名、たとえばgroup1.threadsを選択します。

    以下のようにJMeterスレッドグループの以下のプロパティを設定してください: $ {__ property(group1.threads)}このスレッドに返信します...返信>

    のJMeterを起動するときに、コマンドラインでプロパティを定義します。

    のJMeter -Jgroup1.threads = 10

    +0

    starttimeのパラメータでJmeterを実行すると、これは実行時ではありません。テストの実行中にどのようにパラメータを変更できますか? –

    2

    この機能は、さえのような商用ツールと確かに便利、かつ実装が意外と難しいですLoadrunner。私はそれをスピーカーの最大音量を見つけることと比較します。手動で音量を上げて、音が鳴り始めるまで戻し、音量をわずかに下げて最大音量を維持します。同じように、アプリケーションのピーク容量を見つけるには、エラーが表示されるまで「音量を上げる」ように制御し、安定しているかどうかを少し下に戻します。その負荷を維持して、ボトルネックがどこにあるかを見つけることができます。

    とにかく、私が過去に行ったことは、ファイル名などの外部の影響を使用することです。そして、それをスレッド固有の参照と組み合わせて、どのスレッドが実行され、どのスレッドが保持されているか(一時停止またはそれに類似している)を制御できます。

    たとえば、100スレッドで開始し、特定の場所に '5.txt'というファイルを作成すると、スレッドが自身の参照が番号を入力すると実行できます。そうでなければ、それは一時停止に落ちる。この例の開始時に5つのスレッドが実行され、95が一時停止します。ファイルの名前を'25 .txt 'に変更すると、スレッド6〜25が実行を開始します。それはもう一方の方法でも動作し、'20 .txt 'に変更すると、スレッド21-25が再び一時停止することになります。

    キーは予想ピークを超えるのに十分なスレッドを開始することです。

    +0

    これは、Soasta CloudTestの「販売機能」の1つで、オンザフライで音量を11に変更することができます....これが重要な機能であれば、CloudTestを見ることができます。 –

    0

    私たちのサイトのユーザーを予測することはできません。

    もちろん可能です。これは、既存のサイトのHTTPログが対象となります。 OmnitureやCDNログなどのツールのログを使用することもできます。実際のユーザーのIPアドレス、要求、およびリファラータグの組み合わせをログに記録すると、サイト上の単一ユーザーのトラバーサルマップを構築できます。特定のビジネスプロセスの高ヒットの固有のリーフノードページをプロファイルして、特定のビジネスプロセスが1時間に何回発生するかを理解することができます。 Omnitureなどのツールで漏斗を見て放棄を調べることができます。この分析にツールが必要な場合は、Splunkをお勧めします。インストールと設定は簡単です。価値の時間は非常に速いです。

    あなたが近くにプロファイルするために使用しているログデータが多いほど、日/週/月/スポット販売/四半期/年末/年末などの間にユーザーが実際に行うことができます。パフォーマンステストモデルでの成長を可能にする必要があるため、時間の経過とともにプロジェクトの成長を予測するためには、ある時点で実際のものと以前の時点からの実際のものを組み合わせる必要があります。

    値を正しく取得しないと、本番で何が起きるか予測するためのテストの価値はかなり低くなります。これは、任意のツールの障害ではなく、テスト要件の一部として使用される実際の負荷モデルの計画立案プロセスの失敗です。これらのモデルを作ることができない場合は、できる人をあなたのチームに引き込む必要があります。

    ツールとは独立した有効な負荷モデルを生成するこの能力は、リスクを低減するテストと負荷をスローするテストの違いです。

    関連する問題