On 13 June 2012 01:14, Anthony Johnson <ans...@gmail.com> wrote:
> On Tue, Jun 12, 2012 at 7:06 PM, sebb <seb...@gmail.com> wrote:
>>
>> On 12 June 2012 23:42, 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.
>>
>> 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.
There's a drop-in element pair:
+ If Controller, condition: ${__counter(FALSE)} > 10000
+ + Test Action/Stop Thread.
Theres a trade-off here: the work to add specialised elements (and
documenting/maintaining them) versus the user needing to combine
existing elements to perform the same function. And of course the more
elements there are, the more the user needs to read to find the exact
element they need.
>>
>> > 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
>>
>
> ---------------------------------------------------------------------
> 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
