sorry i think i misread your email. >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. Cant you already do this? fix the duration of the test instead of the number of times you want to run . still seems unrelated to kirk's request :)
On Tue, Jun 12, 2012 at 4:01 PM, Robin D. Wilson <[email protected]> wrote: > 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:[email protected]] > 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 <[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. > > > > 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] > >
