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
