sebb wrote:
On 05/12/2008, kirk <[EMAIL PROTECTED]> wrote:
Hi Sebb,
I guess I should add my work around is to set the thread count for the
thread group to some wild a$$ large value, set the ramp-up time to the
duration that I'd like the test to run, and then set the loop count to 1
which allows the thread to die when it's finished executing the test plan.
That sounds weird.
Well, not really. JMeter as it is currently implemented is good for
simulating close systems such as call centers where there are a fixed
number of users rolling over a set of usage patterns. It is less suited
for open systems where the number of users may vary and entry into the
system is pretty much unthrottled. Unfortunately this represents the
vast majority of systems that I bench/tune. So this scheme with a
randomizer on the front end is more representative of the type of
testing that I do.
I always use JMeter in my performance talks that I often do at
conferences. I'll be presenting a university session at Devoxx (formally
Javapolis) where I'll be using JMeter to load test the demo app. I'll be
presenting this method of load testing on Tuesday.
The throughput controller at the top of the test plan seems to throttle
things the way I was hoping for.
The Throughput Controller is badly named - it does not actually
control throughput, it merely controls the number of executions. You
should probably be using the Constant Throughput Timer.
Humm, I don't think constant throughput is what I'd like either then. I
need to re-think this part.
That said, I've not done a proper
statistical analysis of behavior to confirm. The added advantage of doing
this is that is turns jmeter testing from being closed (self throttling) to
open system.
Not sure I understand what that means.
One of the things that I run into are badly configured stress test
harnesses. Because of this I often validate the harness prior to using
to actually drive a load test. I just want to make sure that the traffic
coming from the harness is what I expect it to be from the server's
point of view. That typically requires doing some sort of statistical
analysis on data generated by a *null* server.
I did have one client that delayed their release because they couldn't
meet critical performance requirements. Turned out the bottleneck in the
system was in the test harness (not JMeter ;)). Once the harness was
tuned, the application managed to just meet requirements. Just two weeks
ago I ran into another similar situation so.....
This loads my systems in a way that is better representative of
the load I'm trying to simulate. What I'm seeing is the requests are coming
in a regular intervals which isn't something that I like. To that point I'd
like the throughput controller to incorporate a Poisson distribution. Best
would be a new type of thread group I'd call a throughput thread group.
Something where I could specify a inter- new user arrival rate with a
distribution. Something that works similarilly to the hack that I'm
currently using only better.
There is currently no Poisson timer, but there are other timers that
you can use, e.g.
http://jakarta.apache.org/jmeter/usermanual/component_reference.html#Gaussian_Random_Timer
Gaussian is good but for this case, Poisson is more appropriate. It's been on
my list for a while to create one.. time...
Regards,
Kirk
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
