jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Deepak Shetty <shet...@gmail.com>
Subject Re: JMeter threading model
Date Tue, 12 Jun 2012 22:47:25 GMT
>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 <rwilson2@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:sebbaz@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.pepperdine@gmail.com> wrote:
> >
> > On 2012-06-13, at 12:54 AM, sebb wrote:
> >
> >> On 12 June 2012 22:06, Kirk Pepperdine <kirk.pepperdine@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-unsubscribe@jmeter.apache.org
> > For additional commands, e-mail: user-help@jmeter.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
> For additional commands, e-mail: user-help@jmeter.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
> For additional commands, e-mail: user-help@jmeter.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message