jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From kirk <>
Subject Re: thread group thread behavior
Date Fri, 05 Dec 2008 13:40:36 GMT
sebb wrote:
> On 05/12/2008, kirk <> 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.
Gaussian is good but for this case, Poisson is more appropriate. It's been on my list for
a while to create one.. time...


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message