Well I did some more testing and I have to say that I'm still confused. All I can figure is that I am misunderstanding how the constant throughput timer works.
I was able to configure the throughput timer to get the same results as I did without it (6000 req/sec) but I had to set the total throughput value on the timer to be really high (about 2,000,000 req/min). I would think the number should be around 360,000 but for some reason that's not enough. This is using the "all active threads in the current thread group" mode. I tried using the "this thread only" mode. I set the test up with 200 threads and the throughput timer to have each thread run at 1800 req/min. According to my understanding, that is 200 threads each pumping out 30 requests per second for a total of 6000 requests per second. Under this configuration my total throughput was only 1400 requests per second. I had to jack up the timer's setting to 22,000 req/min to get the proper throughput. I don't get this. Clearly the server is capable of providing the throughput that I'm looking for. Why do I have to set the timers in such weird ways to get the throughput to the desired level? On Fri, Sep 9, 2011 at 6:57 AM, sebb <seb...@gmail.com> wrote: > On 9 September 2011 04:31, E S <electric.or.sh...@gmail.com> wrote: > > I'm having some trouble getting the Constant Throughput Timer to work the > > way I want in certain cases. > > > > I have a single thread group of 100 threads, all of which are requesting > the > > same resource over and over for 1 minute. > > > > I attached a Constant Throughput Timer on the thread group and ran a > series > > tests with the throughput throttled at higher and higher levels such as > > 6000, 8000, 10000, etc. Here is a table showing the throughput timer > > settings and the actual number of requests that the server under test > > responded to: > > > > thruput-setting..........actual-requests-served > > 36,000.....................36,000 > > 48,000.....................48,000 > > 60,000.....................60,000 > > 72,000.....................60,000 > > 84,000.....................60,000 > > > > So it looks like the server under test simply can't respond to more than > > 60,000 requests per minute right? However, when I disable the throughput > > timer I get way higher throughput, something like 350,000 requests per > > minute. What's going on here? Why is the throughput timer giving me these > > results? Is it possible that JMeter is spending so much time trying to > keep > > the throughput at the right level that it doesn't have enough cycles left > to > > dedicate to actual requests? I tried distributing the load across > multiple > > load generators but it didn't seem to help. > > > > The results above have the throughput timer configured using Calculate > > Throughput based on = "all active threads in current thread group". I > tried > > changing this to "all active threads in current thread group (shared)" > and I > > get the maximum results of 350,000 as if the throughput timer was not > even > > there. I must admit I don't understand the difference between the two > > settings, but neither result sounds right. > > > > Any ideas about this? > > Create a test plan using the Java Sampler with timer settings that > correspond to your server. > > Run a test with CTT disabled and check you get the desired throughput > (use Summary Listener). > > You can then experiment with the CTT without needing to take server > and network behaviour into account. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org > For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org > >
