Have you seen Synchronising Timer? This might serve your purpose. There are various ways you can make that generated throughput not-uniform looking, it depends on how you write the test plan, but might take a few try-errors cycles before you get it right.
There are plugins that also tweak throughput, but for as much as I understood from your mail, I would: * use 2 jmeter test scripts * the first is use for the jmeter instances that generate a rather constant throughput (the bigger part of it) - I usually use a) a large pool of threads & b) Throughput timer to limit it to a value. I do a + b in tandem because its the only way to make sure I generate at least X rps no matter what's the server response times. * the second script is for the actual burst; since these might be resource constraining for the test generating machine, the instances of jmeter that run these tests are on individual machines, and they would generate the traffic spikes in whatever fashion I need them too. But keep it simple though. 10.000 requests with 40 threads? sounds ambitious, I guess it depends on the requests. Normally I would advise against your action plan, but I probably don't have all the details. The problem is that applications don't get JUST bursts of requests, most get continuous flows of requests (at least large scale apps do) and the flow fluctuates sinuously throughout a whole day (the biggest bump of the throughput is when target users are most active, of course) and has small spikes (ups and downs) if you zoom in on small periods of 15 minutes. This is why my scripts don't have a finite number of requests defined. They generate traffic (the same amount I want to benchmark against or in order to stress the app under test) untill a certain time, scheduled, when I need to collect results OR whenever I stop the scripts. But its your choice, you scenario is implementable with JMeter. --Adrian S On Sun, Sep 30, 2012 at 11:43 AM, Xenofon Papadopoulos <xpa...@gmail.com>wrote: > I want to run the following test for my webapp: > > - Client should use T threads > - Client should generate R requests per second (rps). Traffic should > *not > * be uniform. Instead, the requests should be generated in bursts of X > items, with X > R, with each burst occurring as soon as possible. > > So if T=40, X = 10,000 and R = 200: > > - At t0, the client attempts to to send 10,000 requests as fast as > possible, using 40 threads. > - After successfully sending the first 10,000 batch, the client waits > until t1 = t0 + 50 sec (X/R). If it takes longer that 50 sec to send the > first batch, an error is generated. > - At t1, the client attempts to send the next 10,000 batch, etc > > Can this be simulated with an existing JMeter configuration or plugin? > > Thanks >
