単一の URL (OpenAM isAlive.jsp サイト) に対して LoadRunner http プロトコル要求を実行すると、100 VUsrs (http) を使用して、毎秒約 1000/900 ヒットのスループットが得られます。
TruClient で同様のテストを実行して、100 個の VUser を実行しようとしましたが、約 40 個の truclient VUser に到達すると、実際にはスループットが低下し、一部の要求は失敗し、スループットは約 0 に低下します (!)
TruClient は、トランザクションの失敗や要求の失敗に敏感ですか? 一部が失敗しているかのように、テスト全体が台無しになりますか?
SUT に対して十分な負荷を生成したいと考えています。
何か考えはありますか？
Load Generator や System Under Test (SUT) ではありません。
どんなコメントでも大歓迎です！
BR マグヌス・フルグルド
あなたの問題はロードジェネレーターにあります。Truclient プロトコルは、Load Generator マシンで実際に REAL ブラウザを開きます。同じマシンで 40 人のユーザーを開くと、RAM と CPU の問題が発生し、ブラウザの動作が遅くなり、動かなくなります。
40 人のユーザーを実行するには、大規模な負荷テスト マシン アレイを準備する必要があります。少なくとも 4 台のコンピューターが必要です。
大量の負荷を生成しようとする場合、これは最も効果的なプロトコルではありません。可能であれば、AJAX または HTTP を使用します。
コビー。
私の仮説は、truclient でユーザー数が 40 から 100 になると、負荷が飽和した単一のジェネレーターがほぼゼロになるというものです。この仮想ユーザー タイプの重要性が、私がその一般的な使用を避け、パフォーマンス テストの焦点を理解していない人々からのある種の「レンダリング」要求がある一握り以下に追いやる理由です。
テストベッドを見てください。少なくとも、ハードウェアが一致するテスト ベッドに少なくとも 3 つのロード ジェネレーターを用意する必要があります。プライマリ ロード用に 2 つ、コントロール セット用に 1 つ。これはコントローラとは独立しています。負荷の大部分を 2 つの「プライマリ ロード」ジェネレーターで実行し、コントロール ジェネレーターで各ビジネス関数タイプの 1 つの仮想ユーザーを実行します。テスト中はトランザクションの応答時間を確認してください
コントロール グループからのトランザクション応答時間がグローバル グループとは異なり始める場合は、問題があります。コントロールグループが同じペースで継続するか、より速くなる一方で、グローバルが平均的に長くなることは、ツールやテストに使用されるプロトコルに関係なく、ロードジェネレーターの苦痛の絶対的な兆候です.
また、負荷の大部分が http で、Truclient がごくわずかであるモデルに移行することも検討してください。Truclient は、他の方法では満たすことができない要件を満たすために実行されます。より高いレイヤーの開発方法を必要とする技術環境があるかもしれませんが、パフォーマンス テストに含めないサード パーティ サービスへの呼び出しを削除する場合は特にそうです。