On 13 June 2012 00:39, Robin D. Wilson <[email protected]> wrote:
> sebb wrote:
>>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.
>
> At the thread group level is exactly what I'm suggesting...
>
> In the meantime, I will setup a csv file with 0-9999 in it (one number per
> row), and see if I can get that to work like you suggest.
I would start with a shorter file and simple test plan ...
> Seems a little clunky, but if it works - no issue.
Just realised, another possibility is:
Thread Group
+ If Controller, condition: ${__counter(FALSE)} > 10000
+ + Test Action/Stop Thread.
+ rest of thread samples
As the Perl mantra goes: TMTOWTDI
> --
> 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 6:07 PM
> To: JMeter Users List
> Subject: Re: JMeter threading model
>
> 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.
>
>> 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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
