1

LoadRunner のシナリオでは、ランダムのソースがいくつかあります。

  • rand（） 関数
  • ランダムな思考時間のデルタ (ランタイム設定)
  • ランダム ペーシング時間コンポーネント (ランタイム設定)
  • ランダム パラメータ (VUGen テストの一部として)

私はそれらの機能を使用しており、それらの疑似ランダム性を受け入れることができました。ただし、これらの機能の少なくとも 1 つを含むすべてのシナリオ実行が疑似ランダムかつ非決定論的に動作するという事実を受け入れることはできません。ペーシングと思考時間)。だから私は2つの実行がまったく同じランダムシーケンスに基づいていることを望みます. つまり、各実行の初期化の一部として、すべての乱数発生器を自分でシードしたいということです。

() を使用srandして、() のシード値を設定できますrand。init 時に特定の (ハードコードされた) シード値を設定するとrand、すべての仮想ユーザーに対して () によって配信されるシーケンスは常に同じになります。VUser ID 番号をシードすると、randすべての vuser に対して異なる () シーケンスを取得することさえありますが、ユーザーごとに実行ごとに同じです。

rand()以外の LR の他の疑似乱数ソースはどうですか? 決定論的なシナリオの動作を得るために、それらすべてをシードする機会はありますか?

それは大いに役立つと思います。

そのようなメカニズムがなければ、結果統計のランダム性を「平均化」するために、非常に長い、および/または非常にトラフィックの多いテストシナリオを計画する必要があります (これに同意しますか?) 私は一日中これを行っています.

4

3 に答える 3

2

すでにカバーされています。4.51からLoadRunnerを使用していますが、ランダムシードを設定できないバージョンを思い出せません。通常、これはコントローラーで設定されたシナリオの実行時設定にあります。ControllerユーザーガイドのAcrobatバージョンを開き、「シード」という用語を検索することで、ご使用のバージョンのLoadRunnerに関するドキュメントを見つけることができます。

于 2010-12-06T14:21:52.747 に答える
2

乱数ジェネレーターのシードは、ロード ランナーのようなシステムでは必須です。完璧な例 - テストしたいコードの変更があります。乱数ジェネレーターをシードし、変更されたコードの有無にかかわらず実行します。実行される関数の順序はランダムですが、両方のテストで同じ順序が使用されます。これにより、コード変更の正確な影響を確認できます。乱数ジェネレーターを確認する機能がなければ、ランダム性を平均化するために、非常に高い負荷の下で非常に長いテストを実行する必要があります。

シードがなければ、2 番目のテストはまったく別のパスを選択します。そして、別の反復で、さらに別の完全に異なるパス。RANDOM シーケンスが必要ですが、REPEATABLE RANDOM シーケンスが必要です。これが、最新のすべての言語で乱数ジェネレーターをシードできる理由です。Load Runner クライアントは、乱数ジェネレーターの「シード値」を入力できるテキスト フィールドを 1 つ追加するだけです。

于 2010-11-05T16:11:09.260 に答える
0

あなたの質問に対する簡単な答えは: NOです。

Random implies just what it says => "Random".

パラメータの「組み込み」のランダム機能を使用すると、内部のランダムシードがどのように初期化されるかを制御できず、次の値をまったく予測できないため、かなり混乱します。

最終的に達成したいことが、結果を推定し、負荷がかかった状態でのサーバーの動作を予測することである場合、非常に困難な道を歩むことになります。

結果の外挿

Your run with 100 vusers and achieve an avg. of 50-60 hits/sec with
response times under 3 sec.

Logically 1000 vusers (10x load) would give you 500-600 hits/sec ... 

But what about the response times? How do you extrapolate them? How do you know
when the web-server(s) chokes and achieves it's knee-point?

1 秒あたりのヒット数は応答時間に正比例することに注意してください。したがって、1 秒あたりのヒット数 (または 1 秒あたりのページ数) を予測することは非常に難しく、不正確になります。

コントロールできないこと

別の実行の「正確な」コピーを達成したとしても、応答時間とネットワークの遅延に対処する必要があります。これは、状況に関係なく、実際には常に異なります (また、完全に制御できません)。

負荷を定義するより「現実的な」方法

負荷テスト自体は正確な科学ではなく、負荷テストで現実世界を完全にシミュレートすることはできませんが、近づくことはできます。ここで行う方法は、個々のユーザーを可能な限り近くでシミュレートすることです。このようにして、ユーザーのタイプに応じて負荷の期待値を設定できます。これは、「ビジネス」の人々が通常知っていることです。

また、「ユーザー」をパワーユーザー、通常ユーザー、初心者ユーザーなどのタイプに分類します。これらの違いは、操作の速度 (および UI の使用方法) です。

これを行うことで、ページ/秒またはヒット/秒の値やその他のテクニカル メーターではなく、特定の「予想されるユーザー ロード」でターゲット アプリケーションを「ロード」できます。

サービスが時間の経過とともにどのように動作するかを確認するために、より長い実行も実行するため、耐久性テスト フェーズでは 72 時間以上のテストは珍しくありません。これはまた、サーバーで時間の経過とともにメモリ リークが発生しているかどうか、およびバックグラウンド プロセスが「夜間」のサーバー パフォーマンスにどのように影響するかを示します。

于 2010-07-07T09:18:32.640 に答える