Clarification regarding the Throughput Controller across thread groups

[Shmuel Krakower <sh...@gmail.com>]

Hi

I am using the Throughput Controller across several thread groups which
build up my load test scenario.
I'm having a strange issue where I believe is caused by the fact that the
throughput controller is sharing the calculation across all thread groups
if the "Per User" is not marked and I use the "percent executions".

As it is not clear from the documentation, my question is what is the
designed sharing mode of the Throughput Controller if the "Per User" is not
set and calculation based on Percent Executions? Is it shared across all
threads in the specific thread group or across all threads across all
thread groups?

Best,

Shmuel Krakower.
www.Beatsoo.org - re-use your jmeter scripts for application performance
monitoring from worldwide locations for free.

Re: Clarification regarding the Throughput Controller across thread groups

[Shmuel Krakower <sh...@gmail.com>]

Just as a closure for this question.
I've looked into the implementation and indeed there was a bug where
several thread groups may hang each other, but in any case this was not to
do with affecting the result of the calculation of the Throughput
Controller (I'm referring to
http://svn.apache.org/viewvc/jmeter/trunk/src/components/org/apache/jmeter/control/ThroughputController.java?r1=1442366&r2=1442365&pathrev=1442366
and
http://svn.apache.org/viewvc/jmeter/trunk/src/components/org/apache/jmeter/control/ThroughputController.java?r1=1437169&r2=1437168&pathrev=1437169).

In my case the issue was probably due to the fact that I had a Constant
Throughput Timer with lower throughput than amount of threads in the thread
group.
This caused the same threads to ALWAYS skip the Throughput Controller
condition.
(i.e. having 10 threads with constant timer of 1 per minute and a
throughput controller of 20% causing over the long run to see only couple
of threads actually go into the condition and they will mostly remain the
same two threads on the long run)

Setting less threads in the thread group to meet with the Constant
Throughput Timer, resolved my issue.

Shmuel Krakower.
www.Beatsoo.org - re-use your jmeter scripts for application performance
monitoring from worldwide locations for free.


On Wed, Mar 12, 2014 at 5:25 PM, Shmuel Krakower <sh...@gmail.com> wrote:

> Thanks for the quick response Adrian.
> I'll wait for someone with the source code in hand to answer regarding the
> design of this timer.
>
> www.beatsoo.org - free application performance monitoring from world wide
> locations.
> On Mar 12, 2014 5:20 PM, "Adrian Speteanu" <as...@gmail.com> wrote:
>
>> Hi,
>>
>> I have used it several times, in a single thread group and I always
>> assumed
>> (and validated) that it represents a fixed % of all requests, from all
>> threads (per user wasn't set). I.e.: the samplers under this controller
>> represented 2% of all transactions recorder, just like the controller was
>> configured.
>>
>> However, I haven't got the chance to use it since version 2.9 or 2.10, I
>> think, as Constant throughput timer suits my test cases better and gives
>> me
>> the chance to make other interesting configuration.
>>
>> In addition, be careful of nesting of such timers/controllers, some bugs
>> were found in the past due to this and it causes problems with
>> understanding/designing the scenario covered by the script.
>>
>> Cheers,
>> Adrian S
>>
>>
>> On Wed, Mar 12, 2014 at 3:48 PM, Shmuel Krakower <sh...@gmail.com>
>> wrote:
>>
>> > Hi
>> >
>> > I am using the Throughput Controller across several thread groups which
>> > build up my load test scenario.
>> > I'm having a strange issue where I believe is caused by the fact that
>> the
>> > throughput controller is sharing the calculation across all thread
>> groups
>> > if the "Per User" is not marked and I use the "percent executions".
>> >
>> > As it is not clear from the documentation, my question is what is the
>> > designed sharing mode of the Throughput Controller if the "Per User" is
>> not
>> > set and calculation based on Percent Executions? Is it shared across all
>> > threads in the specific thread group or across all threads across all
>> > thread groups?
>> >
>> > Best,
>> >
>> > Shmuel Krakower.
>> > www.Beatsoo.org - re-use your jmeter scripts for application
>> performance
>> > monitoring from worldwide locations for free.
>> >
>>
>

Re: Clarification regarding the Throughput Controller across thread groups

[Shmuel Krakower <sh...@gmail.com>]

Thanks for the quick response Adrian.
I'll wait for someone with the source code in hand to answer regarding the
design of this timer.

www.beatsoo.org - free application performance monitoring from world wide
locations.
On Mar 12, 2014 5:20 PM, "Adrian Speteanu" <as...@gmail.com> wrote:

> Hi,
>
> I have used it several times, in a single thread group and I always assumed
> (and validated) that it represents a fixed % of all requests, from all
> threads (per user wasn't set). I.e.: the samplers under this controller
> represented 2% of all transactions recorder, just like the controller was
> configured.
>
> However, I haven't got the chance to use it since version 2.9 or 2.10, I
> think, as Constant throughput timer suits my test cases better and gives me
> the chance to make other interesting configuration.
>
> In addition, be careful of nesting of such timers/controllers, some bugs
> were found in the past due to this and it causes problems with
> understanding/designing the scenario covered by the script.
>
> Cheers,
> Adrian S
>
>
> On Wed, Mar 12, 2014 at 3:48 PM, Shmuel Krakower <sh...@gmail.com>
> wrote:
>
> > Hi
> >
> > I am using the Throughput Controller across several thread groups which
> > build up my load test scenario.
> > I'm having a strange issue where I believe is caused by the fact that the
> > throughput controller is sharing the calculation across all thread groups
> > if the "Per User" is not marked and I use the "percent executions".
> >
> > As it is not clear from the documentation, my question is what is the
> > designed sharing mode of the Throughput Controller if the "Per User" is
> not
> > set and calculation based on Percent Executions? Is it shared across all
> > threads in the specific thread group or across all threads across all
> > thread groups?
> >
> > Best,
> >
> > Shmuel Krakower.
> > www.Beatsoo.org - re-use your jmeter scripts for application performance
> > monitoring from worldwide locations for free.
> >
>

Re: Clarification regarding the Throughput Controller across thread groups

[Adrian Speteanu <as...@gmail.com>]

Hi,

I have used it several times, in a single thread group and I always assumed
(and validated) that it represents a fixed % of all requests, from all
threads (per user wasn't set). I.e.: the samplers under this controller
represented 2% of all transactions recorder, just like the controller was
configured.

However, I haven't got the chance to use it since version 2.9 or 2.10, I
think, as Constant throughput timer suits my test cases better and gives me
the chance to make other interesting configuration.

In addition, be careful of nesting of such timers/controllers, some bugs
were found in the past due to this and it causes problems with
understanding/designing the scenario covered by the script.

Cheers,
Adrian S


On Wed, Mar 12, 2014 at 3:48 PM, Shmuel Krakower <sh...@gmail.com> wrote:

> Hi
>
> I am using the Throughput Controller across several thread groups which
> build up my load test scenario.
> I'm having a strange issue where I believe is caused by the fact that the
> throughput controller is sharing the calculation across all thread groups
> if the "Per User" is not marked and I use the "percent executions".
>
> As it is not clear from the documentation, my question is what is the
> designed sharing mode of the Throughput Controller if the "Per User" is not
> set and calculation based on Percent Executions? Is it shared across all
> threads in the specific thread group or across all threads across all
> thread groups?
>
> Best,
>
> Shmuel Krakower.
> www.Beatsoo.org - re-use your jmeter scripts for application performance
> monitoring from worldwide locations for free.
>