Hi all,
The problem here is not in a difference between GUI and headless
performance, it is in one of two other problems. Either your test is ill
defined or you are starving your test for threads. Let me explain.
First the JMeter Thread Group equate a user to be a thread. IMHO, this
is the wrong way to think about a load test. A better way to think about
this is arrival rates for requests to the server. The throughput measure
is a rough estimate of this but do remember that even that measure is
flawed because it reflect rates of exit from the system which in JMeter
happens to equal rates of entry into the a system. This behavior is
typical of closed systems. For example, think call center where
operators are the end users. In that system an operator will service a
customer from the queue and when they are done with that customer, they
go and get another customer from the queue. From the computers systems
point of view, there are a fixed number of users on the system at all
times (ok, not a lower loads but I think you get the point) and that
once a user does leave the system, it is almost immediately replaced. If
this is your situation than your timings in your jmeter script are not
stable or otherwise broken.
The other situation is an open system in which rate of entry is not tied
to rate of exit. This type of system is difficult to model in JMeter.
Since there is no direct support for open system simulation in JMeter
(not picking on JMeter here, this is a common omission in many test
harnesses) you have to figure out a different way to maintain some
constant inter-request arrival rate on the server. My idea in the past
has been to.
1) Calculate the frequency at which users arrive to the system. Lets
call this F
2) Determine the duration that you want to run your test. Let call this D
3) in the properties sheet for the thread group, set the number of
threads to F*D, the ramp up to the test duration, and the repeat count to 1.
This will cause JMeter to pulse the first request of the thread group to
the server on a schedule determined by the rampup behavior. However this
behavior being constant, isn't desirable either. To counter this you
need to add a timer to effectively randomization into the pulse. The
spread of the randomization should match the expected spread on the
average rate at which users will enter the system.
If you do this I think you should see the responses time difference
between headless and GUI disappear. In other words, this effect is due
entirely to the harness and that is a sure fire sign that the harness is
broken or mis configured.
Good luck,
Kirk
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
