Re: JMeter threading model
sebb <sebbaz <at> gmail.com>
2012-06-13 00:24:49 GMT
On 13 June 2012 01:14, Anthony Johnson <ansoni <at> gmail.com> wrote:
> On Tue, Jun 12, 2012 at 7:06 PM, sebb <sebbaz <at> gmail.com> wrote:
>> On 12 June 2012 23:42, Robin D. Wilson <rwilson2 <at> 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.