>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. If so , your test needs more than 1 machine to run and the threads on demand wont really help your use case.
On Tue, Jun 12, 2012 at 3:42 PM, Robin D. Wilson <rwils...@gmail.com> wrote: > 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 > >
