Currently, JMeter will run 100 threads, for 100 iterations each in order to reach 10,000 total passes through my test case. If thread 1 completes its 100 iterations before any of the rest of the threads, it terminates and then I only have 99 threads running until the 10,000 iterations complete. My test will show a performance change at the end - as the number of total simultaneous threads begins to trail off, the performance will appear to improve. For example, I will show the sampler as having completed 9200 requests when the first thread finishes its 100 iterations. This means for the remaining 800 requests, I only have a maximum 99 threads operating. Then at 9300 samples, 19 more threads might have died off - so I only have 80 threads max operating for the remaining 700 requests. As you can imagine, this means that by the end of the test - the performance numbers will start to progressively improve (since fewer threads means less workload on the process being measured, and therefore faster response times).
It would be really nice if JMeter just kept a pool of 100 threads operating on requests for the duration of the 10,000 iterations, so that threads would only die off during the final iteration, leaving the server at more-or-less peak load throughout the test. >From a code standpoint, this doesn't seem like it would be too hard to setup - >just identify how many total iterations need to be run through the thread group, startup the total number of threads you need, and let each thread keep going until all the iterations have been started. (Of course, I say that knowing that I'm just a 'manager' type, and won't be coding it myself...) -- Robin D. Wilson Sr. Director of Web Development KingsIsle Entertainment, Inc. VOICE: 512-777-1861 www.KingsIsle.com -----Original Message----- From: sebb [mailto:seb...@gmail.com] Sent: Tuesday, June 12, 2012 5:02 PM To: JMeter Users List Subject: Re: JMeter threading model On 12 June 2012 22:57, Kirk Pepperdine <kirk.pepperd...@gmail.com> wrote: > > On 2012-06-13, at 12:54 AM, sebb wrote: > >> On 12 June 2012 22:06, Kirk Pepperdine <kirk.pepperd...@gmail.com> wrote: >>> Hi, >>> >>> I figured thread pooling would be revolutionary so I wasn't suggesting >>> that. I would be very useful just delay the creation of a thread until it was asked for. >> >> Not sure I understand how it would help to delay the thread creation, >> except perhaps for the case where the first threads have finished >> processing by the time the last threads start running samples. > > Bingo!!! ;-) So what percentage of use cases need to follow this model? Most of the JMeter testing I have done was long running tests where all threads were active for most of the run. > Kirk > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org > For additional commands, e-mail: user-h...@jmeter.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org
