I'm not sure I follow... My JMeter test runs on a single Win7 box. My test environment consists of a web server, multiple Java App servers and a database server. The performance appears to improve because I'm hitting the test environment with fewer and fewer threads as the test begins to wrap up. I'm just saying that it would be nice if I could delay that drop-off until I get to the last 100 samples, rather than several hundred samples before the test ends. It probably doesn't make a big difference to me - since I'm really just comparing the results of the last time I ran the test against the results of this time. But it would make my test a better measure of operating characteristics of my system 'under load' to have it consistently maintain the full number of requesting threads throughout the test.
-- Robin D. Wilson Sr. Director of Web Development KingsIsle Entertainment, Inc. VOICE: 512-777-1861 www.KingsIsle.com -----Original Message----- From: Deepak Shetty [mailto:shet...@gmail.com] Sent: Tuesday, June 12, 2012 5:47 PM To: JMeter Users List Subject: Re: JMeter threading model >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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org
