jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William Oberman <>
Subject Re: constant rate testing (again)
Date Mon, 26 Jul 2010 20:32:42 GMT
Well, this is weird/irritating.  No matter what I do I can't create
more than certain amount of load with JMeter.  For example, if I run
one server at full throttle, I might get 75 req/sec.  If I run two
servers with the same size thread pool, I then get ~37 req/sec.  If I
run three servers with the same size thread pool, I get 25 req/sec.
And so on.

I guess this problem is more complicated than I thought without Jmeter
having a specific feature to generate constant inbound load (or
dropping connections slower than X seconds, which I think would also


On Mon, Jul 26, 2010 at 1:40 PM, William Oberman <> wrote:
> I found an old email thread about doing constant rate testing in the
> archives.  I wanted to kick the idea up again, but first I'll review
> the basic situation, and past advice:
> -I want to simulate a constant inbound rate, so that if the server
> falls behind the inbound load keeps coming and crushes the server
> -Jmeter has a fixed pool size + every thread waits for a response, so
> jmeter will in effect "slow down to accommodate" the load
> -The advice from the old thread (my interpretation) was basically find
> a thread pool size large enough to crush the server
> The "next step" problem the user in the old thread appeared to be
> having was the inability to scale Jmeter to "crushing load" levels.  I
> don't have that problem... I can create thread pools that create
> crushing load.  But, I'd vastly prefer to create the real world use
> case of constant inbound load.  I was wondering if there is a clever
> use of the Constant Throughput Timer (CTT) that will help?
> I haven't used the CTT much before, but based on the description, it
> seems promising.   My basic idea was going to be:
> -Have a thread group with size greater than the "crushing level"
> -Use the CTT (or CTTs) to throttle the huge thread pool to keep most
> threads idle
> -As the server experiences load and slows down, the CTTs will continue
> to let previously idle threads run (to keep the rate at a certain
> level), hopefully slowing increasing the load to the crushing point
> I'm obviously still playing around, trial and error style.  But, I
> thought I'd check here in case there is a fundamental flaw I'm missing
> (or an easier approach).  Or is all of this complicated setup == a
> large thread group + long ramp up period?  I'll try that too...
> will

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

View raw message