実行時に JMeter テスト計画のスレッド数を変更したいと考えています。
私は自分の問題をグーグルで検索し、JMeter プラグインを使用するための提案された解決策を見つけました。しかし、このソリューションでは、テスト計画を実行する前にスレッド グループをスケジュールする必要があり、これは望ましくありません。 プロパティを変更するが、実行時のテスト計画の動作には影響しない別の潜在的な解決策も見つけました。
最終的に、私がやろうとしているのは、スレッド グループで指定されたスレッド番号を変更し、現在実行中のテスト計画のスレッド数をすぐに増減させることです。
これは可能ですか？
IMHO は、適切なパフォーマンス テストを実行する際に実際のメリットがない単なる派手な機能です。関連するテスト出力 (レポート) を生成するには、再現性と、明確に定義されたテスト方法論とシナリオが必要です。アプリケーション/サーバー/インフラストラクチャの変更の影響を比較するには、再現性が必要です。
どういう意味
サイトのユーザーを予測することはできません
そのため、最初にパフォーマンス テストを行います。アプリケーション/インフラストラクチャの制限を調べるため。
つまり、作成できる最も重要なメトリックは、並列ユーザーの数が変化したときにアプリケーションの応答時間がどのように変化するかです。ただし、実行時に不規則に変更しないでください。
jMeter プラグインの Ultimate スレッド グループを使用すると、考えられるあらゆるシナリオに対応できます。
簡単な答えは次のとおりです。いいえ、実行時にスレッドの数を動的に変更することはできません。各スレッドカウント値は、テストプランが最初にコンパイルされたときに一度だけ読み取られ、この時点以降は再度解決されないため、固定されたままになります。
起動スレッドで設定した変数に基づいて変更できます。下記参照。
Jmeterでは、beanshellサンプラー変数を使用して可変数のスレッドを設定するにはどうすればよいですか?
ただし、スレッド グループが開始されると、それを変更することはできません。この機能が役に立たないと言った人には同意しません。負荷テストには多くの種類があり、期間中にすべて同じ数のユーザーが実行されるわけではありません。以下に、私が勤務する銀行で実施しているエンタープライズ ロード テストの 2 つのタイプの例を示します。
ブレーク ポイント テストでは、アプリケーションが壊れるまでユーザー数を増やします (ポイントは、アプリがどれだけスケーリングできるかを確認することです)。スレッドグループの「ランプアップ期間」プロパティを使用して、これを行うことができます。ランプアップ時間を 1000 に設定し、スレッド数を 100 に設定すると、10 秒ごとに 1 つのスレッドが追加されます。
スパイク テストは持続時間テストに似ていますが、ある間隔で多数のユーザーがログインします。これは、ピーク時のアプリケーションの応答時間や、突然多数のユーザー (非常に実際のシナリオ）。
Jmeter は、エンタープライズ負荷テストに必要なすべての負荷テスト シナリオを処理できるわけではありません。私が検討している回避策の 1 つは、すべてのスレッドを開始するだけで、スレッドの一部をスリープ状態にする方法を見つけることです。したがって、スレッド数を 1000 に設定しても、そのうち 980 スレッドをスリープ状態にするか、何もしないようにすることができます。次に、time_in_seconds%5==0 (5 分ごと) のときに、他のスレッドの実行を許可して、スパイク テストをシミュレートします。アイデアは、スレッドを 1000 にハードコーディングでき、常に 1000 のスレッドが実行されるようにすることができますが、すべてのスレッドが常に何かを実行している必要はありません。
（言い換えれば、おそらく方法を見つけることができますが、創造的になる必要があります）
更新: さまざまな種類のテストを可能にするこのプラグインを見つけました。まだ試していませんが、有望に見えます: http://jmeter-plugins.org/wiki/ThroughputShapingTimer/
当サイトのユーザーを予測することはできません。
できますよ。これが、既存のサイトの HTTP ログの目的です。Omniture や CDN ログなどのツールからのログを使用することもできます。ログ内の実際のユーザーの IP アドレス、リクエスト、リファラー タグの組み合わせを見ると、サイト上の単一ユーザーのトラバーサル マップを作成できます。特定のビジネス プロセスのヒット率の高い一意のリーフ ノード ページをプロファイリングして、特定のビジネス プロセスが 1 時間に何回発生するかを把握できます。Omniture などのツールでじょうごを調べることで、放棄を調べることができます。この分析用のツールが必要な場合は、Splunk をお勧めします。インストールと構成は簡単です。価値実現までの時間は非常に短いです。
プロファイリングに使用しているログ データが多ければ多いほど、ユーザーが日/週/月/スポット セール/四半期末/年末/などに行った実際の行動に近づくことができます。ある時点の実績と以前の時点の実績を組み合わせて、時間の経過に伴う成長を予測します。これは、パフォーマンス テスト モデルの成長を考慮する必要があるためです。
値を正しく取得しない場合、本番環境で何が起こるか、または起こり得るかの予測因子としてのテストの価値は非常に低くなります。これは特定のツールの失敗ではなく、テスト要件の一部として使用される実際の負荷モデルの計画段階での失敗です。これらのモデルを構築できない場合は、できる人をチームに引き込む必要があります。
ツールに依存しない有効な負荷モデルを生成するこの機能は、リスクを軽減するテストと負荷をスローするテストの違いです。
コマンドラインオプションを使用して、実行時にスレッドの数を設定/変更できます...
関数呼び出し、ユーザー パラメーターへの変数参照 (これは関数である可能性があります)、またはテストの早い段階で関数によって設定された変数への変数参照を使用できます。それを行う方法は複数あります。
テスト計画のスレッド数を変更できるようにしたいとします。group1.threads など、適切なプロパティ名を選択します。GUI (勇気がある場合は JMX) のスレッド数を次の関数呼び出しに置き換えます。
${__property(group1.threads)} のように、JMeter スレッド グループで以下のプロパティを設定してください。
次に、JMeter の起動時に、コマンド ラインでプロパティを定義します。
jmeter -Jgroup1.threads=10