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 work) will On Mon, Jul 26, 2010 at 1:40 PM, William Oberman <ober...@gmail.com> 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: jmeter-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org
