On Tue, Jun 12, 2012 at 7:06 PM, sebb <[email protected]> wrote: > > On 12 June 2012 23:42, Robin D. Wilson <[email protected]> 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. > > JMeter can do this already. > Rather than specify a fixed number of loops, use a CSV Config file > with 10,000 entries, and set it to stop the thread (not the test, as > that would not let some threads complete) when EOF is reached. > > For tests where a CSV data file is not appropriate or convenient, it > might make sense to implement a feature which counts total loops and > causes the test to stop when a pre-specified limit is reached. Perhaps > at thread group level, which already has a duration limit. Or a test > element of some kind.
It would be nice if their was a drop-in element for this. My team created a test flow that did exactly this, but it was more work than it should of been. > > > 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:[email protected]] > > 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 <[email protected]> > > wrote: > >> > >> On 2012-06-13, at 12:54 AM, sebb wrote: > >> > >>> On 12 June 2012 22:06, Kirk Pepperdine <[email protected]> > >>> 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: [email protected] > >> For additional commands, e-mail: [email protected] > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
