1

I run a LoadRunner http-protocol request against a single url (OpenAM isAlive.jsp site) and I get about 1000/900 hits per seconds throughput using i.e. 100 VUsrs (http).

Running the similar test with TruClient I try to run 100 VUseres and when I reach about 40 truclient VUsers the throughput actually decreases and some requests are failing and throughput godes down to about 0 (!)

Is TruClient sensible to failing transactions and/ or missed requests? As if some are failing it would ruin the whole test?

I want to generate enough load against my SUT.

Any thougts?

It is not the load generator nor the system under test (SUT).

Any commmets would be greatly appreciated!

BR Magnus Fuglerud

CodeWizard
  • 128,036
  • 21
  • 144
  • 167
Magnus Jensen
  • 905
  • 6
  • 36
  • 73

2 Answers2

3

Your problem is in the load generators. Truclient protocol actually opens a REAL browser on the load generator machine. When opening 40 users on the same machine, you are causing RAM and CPU issues, which cause the browser to perform slowly and get stuck.

You should prepare a massive load test machine array, for running 40 users I would say you need at least 4 computers.

It's not the most effective protocol to work with when trying to generate massive load. If possible, I would work with AJAX or HTTP.

Koby.

Koby Douek
  • 16,156
  • 19
  • 74
  • 103
1

My hypothesis is that you have a single saturated load generator which is slowing to almost zero as you go from 40 users to 100 under truclient. The weight of this virtual user type is why I shy away from its general use and relegate it to a handful or less where there is some sort of "rendering" demand from people who do not understand the focus of performance testing.

Look to your test bed. Minimally you should have at least three load generators in your test bed, hardware matched. Two for primary load and one for a control set. This is independent of the controller. Run the majority of your load on the two "primary load" generators and one virtual user of each business function type on the control generator. Watch your transaction response times during the test

If you see the transaction response times from your control group begin to vary from the global group you have a problem. Global getting longer on average while the control group continues at the same pace or gets faster is an absolute sign of load generator distress, independent of tool and independent of protocol used for testing.

Also consider moving to a model where the majority of your load is http and only a few are Truclient, where they are being run to satisfy a requirement which cannot be satisfied any othere way. There may be technical environments which demand a higher layer development method, but these are few and far between, especially when you remove the calls to third party services that you would not include in your performance test anyway.

James Pulley
  • 5,606
  • 1
  • 14
  • 14