OnDemand thread group

[sebb <se...@gmail.com>]

I think it's good that the functionality of the onDemand thread group
now exists.

I just wonder why it was not done as an option on the existing thread group?

Seems to me that would be simpler - and also easier to convert
existing test plans if required (or indeed convert back).

Is there a reason why the functionality has to be done as a separate
class, or could the code be incorporated into the existing thread
group?

Re: OnDemand thread group

[sebb <se...@gmail.com>]

On 15 July 2012 00:40, sebb <se...@gmail.com> wrote:
> On 14 July 2012 19:52, Philippe Mouawad <ph...@gmail.com> wrote:
>> Ok , I agree on what you say on alternate implementation.
>>
>> But Regarding what you said previously:
>> "The current fix does not actually address that issue."
>>
>> I don't understand ? Why and if not which issue is not addressed ?
>> Can you in this case clarify what Kirk Pepperdine meant ?
>
> I think he was referring to the ability to start more threads on
> demand as a test progresses, thus allowing more load to be generated
> even if the server under test is not replying fast enough to allow the
> existing threads to generate the load.
>
> The current fix does not address that; the total thread count is
> fixed, and threads are created based on time, not desired load. As
> such, the name OnDemand is ambiguous; it can also mean demand by load
> - and that is probably the more common meaning. It is more like "just
> in time" behaviour (though that's not ideal as a name either).
>
> However the fix does address the special case where there are lots of
> short-lived threads.

It occurs to me that it should be possible to extend the code to
release threads based on load - rather than time as at present.

It would be sensible to start with an initial number of threads which
are expected to be able to create the target load initially.

There needs to be a way to measure the current load, and tell the
ThreadStarter when it needs to start another thread - perhaps use the
Constant Throughput Timer (CTT)  for this?

The CTT could be extended to trigger a new thread if it calculates
that the rate is insufficient.
This would be the case where the calculated wait time is zero or negative.

Maybe the CTT should even be able to stop threads if the calculated
wait time is above a certain threshhold.
[In both cases, these features would not make sense where the CTT is per-thread]

It might be possible to use a Timer/TimerTask for both delayed start
and load-based thread creation - use the appropriate
scheduleAtFixedRate() method for delayed start-up, and schedule() with
zero delay to trigger a new thread. The ThreadStarter just needs to be
prodded at the appropriate time.

>> Thanks
>> Regards
>> Philippe
>>
>> On Sat, Jul 14, 2012 at 6:24 PM, sebb <se...@gmail.com> wrote:
>>
>>> On 14 July 2012 17:04, Philippe Mouawad <ph...@gmail.com>
>>> wrote:
>>> > Hello,
>>> > I understand it differently, what this feature does is that it enables
>>> > creation of thousands of short lived threads while doing so with current
>>> > implementation didn't enable this.
>>>
>>> Yes, that is also true. I should have mentioned that.
>>>
>>> However, this only applies if the threads are relatively short-lived
>>> compared with the total run-time.
>>>
>>> > With Thread Group, to create 10000 threads that run 1 HTTP requests ,
>>> will
>>> > make JMeter create 10000 threads at Test startup before sampling, so we
>>> > will have 10000 threads on first sample, this will require many resources
>>> > and will impact behaviour.
>>> > With On Demand Thread Group there is a big chance that many thread end
>>> and
>>> > that at a one point in Test we have far less running threads than 10000.
>>> > In my tests I see this behaviour.
>>> >
>>> > But maybe I am wrong.
>>>
>>> No, but I still don't see it as a fundamentally different type of thread
>>> group.
>>>
>>> I see it as an alternate implementation which is better suited to some
>>> test scenarios.
>>>
>>> Changing the thread count and ramp-up of an existing test plan may
>>> well require the changing the startup strategy.
>>> This is currently very awkward to do.
>>>
>>> > Regards
>>> > Philippe
>>> >
>>> > On Sat, Jul 14, 2012 at 5:54 PM, sebb <se...@gmail.com> wrote:
>>> >
>>> >> On 14 July 2012 15:39, sebb <se...@gmail.com> wrote:
>>> >> > On 14 July 2012 14:19, Philippe Mouawad <ph...@gmail.com>
>>> >> wrote:
>>> >> >> Hello Sebb,
>>> >> >> I am not sure we shoud use the approach of Http Sampler.
>>> >> >> Because for example a future enhancement I see to OnDemandThreadGroup
>>> >> is to
>>> >> >> add Thread Pooling, and in this case user will input the min/max
>>> size of
>>> >> >> the pool.
>>> >> >> In this case the HttpSampler approach won't fit unless user inputs
>>> >> >> configuration in jmeter.properties.
>>> >> >
>>> >> > Why not? Surely we can just add the extra fields to the GUI?
>>> >> > Or perhaps I'm missing something.
>>> >> >
>>> >> >> I don't see why introducing a new Test Element is a problem.
>>> >> >
>>> >> > More to document; more documentation for users to read.
>>> >> >
>>> >> > At present, the thread groups GUIs are identical apart from the name.
>>> >> > Much easier to support this via an additional checkbox.
>>> >> >
>>> >> >> And why would users want to convert thread group to new one ?
>>> >> >
>>> >> > Because they would like to use the new feature with existing tests.
>>> >> >
>>> >> >> Another point I have in mind is existing plugins that extend
>>> >> >> AbstractThreadGroup, are you sure we won't break them with this
>>> >> approach ?
>>> >> >
>>> >> > That's a separate issue.
>>> >> >
>>> >> >> In my understanding, this Test Element answers a new kind of Test
>>> case
>>> >> if
>>> >> >
>>> >> > It's not so different that it requires a new GUI, unlike the setUp and
>>> >> > tearDown thread groups.
>>> >> >
>>> >> >> you remember what Kirk Pepperdine was saying in initial
>>> conversation:*
>>> >> >> "However, I'm often simulating open systems which means I do not want
>>> >> rate
>>> >> >> of entry into the system to be controlled by the performance of the
>>> >> system
>>> >> >> (rate of exit). "*
>>> >>
>>> >> The current fix does not actually address that issue.
>>> >>
>>> >> Thinking about it further, it seems to me that when the threads are
>>> >> created is an implementation detail, so long as the same total threads
>>> >> are created.
>>> >> Whether threads are created all at once intially, or as their rampUp
>>> >> delay expires, makes no overall difference to the running of the test.
>>> >>
>>> >> In the first case, the thread creation overhead is done at the start,
>>> >> and in the onDemand case, the overhead is spread out over the full
>>> >> rampUp time.
>>> >>
>>> >> For a short ramp-up time, it's probably better to create the threads
>>> >> upfront; for a long ramp-up time it's likely to be better to create
>>> >> threads as they become eligible to run.
>>> >>
>>> >> So another approach would be to automatically change the behaviour of
>>> >> thread creation depending on the number of threads and total ramp-up
>>> >> time.
>>> >> However, getting the algorithm correct is not going to be easy, so the
>>> >> simple solution is for the user to make the choice via a checkbox.
>>> >>
>>> >> >> So I find it Ok to create a new Test Element, but as it's how I build
>>> >> it,
>>> >> >> it's regular I agree with myself :-)
>>> >> >>
>>> >> >> But if you want to change things, go ahead as I am not sure to
>>> >> understand
>>> >> >> how you want to change it.
>>> >> >
>>> >> > I don't know yet how I would change it.
>>> >> > I'll let the list know later.
>>> >> >
>>> >> >> Regards
>>> >> >> Philippe
>>> >> >>
>>> >> >> On Sat, Jul 14, 2012 at 12:57 PM, sebb <se...@gmail.com> wrote:
>>> >> >>
>>> >> >>> On 14 July 2012 09:18, Philippe Mouawad <philippe.mouawad@gmail.com
>>> >
>>> >> >>> wrote:
>>> >> >>> > Hello Sebb ,
>>> >> >>> > I saw 3 reasons which Led me to implementing it this way:
>>> >> >>> > - looking at use case of this feature it seems to me it's
>>> different
>>> >> from
>>> >> >>> > current thread group and you might want to mix the 2 behaviours in
>>> >> one
>>> >> >>> test
>>> >> >>> > plan. For me typical usage of on demand Will be to put lot of
>>> >> threads and
>>> >> >>> > very few iterations , maybe only one
>>> >> >>>
>>> >> >>> As far as I can tell, that does not require a separate test element.
>>> >> >>>
>>> >> >>> > - code of thread group would have been too complex
>>> >> >>> > - currently thread group is not Much impacted and we can improve
>>> on
>>> >> >>> demand
>>> >> >>> > Without risks on existing plans.
>>> >> >>>
>>> >> >>> It may well have made updates somewhat simpler; depends on how the
>>> >> >>> combined thread group was implemented.
>>> >> >>>
>>> >> >>> But is it worth the inconvenience to end users?
>>> >> >>> It's currently not at all easy to convert between the two styles of
>>> >> >>> thread group.
>>> >> >>>
>>> >> >>> I think we need to look again at how the code could be rearranged;
>>> it
>>> >> >>> might be possible to have the best of both worlds.
>>> >> >>> Possibly using something like the approach used for the HTTP
>>> Sampler.
>>> >> >>> If we can keep the same test plan classes, we can add new
>>> >> >>> implementation classes if necessary without breaking test plans.
>>> >> >>>
>>> >> >>> > Regards
>>> >> >>> > Philippe
>>> >> >>> >
>>> >> >>> >
>>> >> >>> > On Saturday, July 14, 2012, sebb wrote:
>>> >> >>> >
>>> >> >>> >> I think it's good that the functionality of the onDemand thread
>>> >> group
>>> >> >>> >> now exists.
>>> >> >>> >>
>>> >> >>> >> I just wonder why it was not done as an option on the existing
>>> >> thread
>>> >> >>> >> group?
>>> >> >>> >>
>>> >> >>> >> Seems to me that would be simpler - and also easier to convert
>>> >> >>> >> existing test plans if required (or indeed convert back).
>>> >> >>> >>
>>> >> >>> >> Is there a reason why the functionality has to be done as a
>>> separate
>>> >> >>> >> class, or could the code be incorporated into the existing thread
>>> >> >>> >> group?
>>> >> >>> >>
>>> >> >>> >
>>> >> >>> >
>>> >> >>> > --
>>> >> >>> > Cordialement.
>>> >> >>> > Philippe Mouawad.
>>> >> >>>
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> --
>>> >> >> Cordialement.
>>> >> >> Philippe Mouawad.
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Cordialement.
>>> > Philippe Mouawad.
>>>
>>
>>
>>
>> --
>> Cordialement.
>> Philippe Mouawad.

Re: OnDemand thread group

[sebb <se...@gmail.com>]

On 14 July 2012 19:52, Philippe Mouawad <ph...@gmail.com> wrote:
> Ok , I agree on what you say on alternate implementation.
>
> But Regarding what you said previously:
> "The current fix does not actually address that issue."
>
> I don't understand ? Why and if not which issue is not addressed ?
> Can you in this case clarify what Kirk Pepperdine meant ?

I think he was referring to the ability to start more threads on
demand as a test progresses, thus allowing more load to be generated
even if the server under test is not replying fast enough to allow the
existing threads to generate the load.

The current fix does not address that; the total thread count is
fixed, and threads are created based on time, not desired load. As
such, the name OnDemand is ambiguous; it can also mean demand by load
- and that is probably the more common meaning. It is more like "just
in time" behaviour (though that's not ideal as a name either).

However the fix does address the special case where there are lots of
short-lived threads.

> Thanks
> Regards
> Philippe
>
> On Sat, Jul 14, 2012 at 6:24 PM, sebb <se...@gmail.com> wrote:
>
>> On 14 July 2012 17:04, Philippe Mouawad <ph...@gmail.com>
>> wrote:
>> > Hello,
>> > I understand it differently, what this feature does is that it enables
>> > creation of thousands of short lived threads while doing so with current
>> > implementation didn't enable this.
>>
>> Yes, that is also true. I should have mentioned that.
>>
>> However, this only applies if the threads are relatively short-lived
>> compared with the total run-time.
>>
>> > With Thread Group, to create 10000 threads that run 1 HTTP requests ,
>> will
>> > make JMeter create 10000 threads at Test startup before sampling, so we
>> > will have 10000 threads on first sample, this will require many resources
>> > and will impact behaviour.
>> > With On Demand Thread Group there is a big chance that many thread end
>> and
>> > that at a one point in Test we have far less running threads than 10000.
>> > In my tests I see this behaviour.
>> >
>> > But maybe I am wrong.
>>
>> No, but I still don't see it as a fundamentally different type of thread
>> group.
>>
>> I see it as an alternate implementation which is better suited to some
>> test scenarios.
>>
>> Changing the thread count and ramp-up of an existing test plan may
>> well require the changing the startup strategy.
>> This is currently very awkward to do.
>>
>> > Regards
>> > Philippe
>> >
>> > On Sat, Jul 14, 2012 at 5:54 PM, sebb <se...@gmail.com> wrote:
>> >
>> >> On 14 July 2012 15:39, sebb <se...@gmail.com> wrote:
>> >> > On 14 July 2012 14:19, Philippe Mouawad <ph...@gmail.com>
>> >> wrote:
>> >> >> Hello Sebb,
>> >> >> I am not sure we shoud use the approach of Http Sampler.
>> >> >> Because for example a future enhancement I see to OnDemandThreadGroup
>> >> is to
>> >> >> add Thread Pooling, and in this case user will input the min/max
>> size of
>> >> >> the pool.
>> >> >> In this case the HttpSampler approach won't fit unless user inputs
>> >> >> configuration in jmeter.properties.
>> >> >
>> >> > Why not? Surely we can just add the extra fields to the GUI?
>> >> > Or perhaps I'm missing something.
>> >> >
>> >> >> I don't see why introducing a new Test Element is a problem.
>> >> >
>> >> > More to document; more documentation for users to read.
>> >> >
>> >> > At present, the thread groups GUIs are identical apart from the name.
>> >> > Much easier to support this via an additional checkbox.
>> >> >
>> >> >> And why would users want to convert thread group to new one ?
>> >> >
>> >> > Because they would like to use the new feature with existing tests.
>> >> >
>> >> >> Another point I have in mind is existing plugins that extend
>> >> >> AbstractThreadGroup, are you sure we won't break them with this
>> >> approach ?
>> >> >
>> >> > That's a separate issue.
>> >> >
>> >> >> In my understanding, this Test Element answers a new kind of Test
>> case
>> >> if
>> >> >
>> >> > It's not so different that it requires a new GUI, unlike the setUp and
>> >> > tearDown thread groups.
>> >> >
>> >> >> you remember what Kirk Pepperdine was saying in initial
>> conversation:*
>> >> >> "However, I'm often simulating open systems which means I do not want
>> >> rate
>> >> >> of entry into the system to be controlled by the performance of the
>> >> system
>> >> >> (rate of exit). "*
>> >>
>> >> The current fix does not actually address that issue.
>> >>
>> >> Thinking about it further, it seems to me that when the threads are
>> >> created is an implementation detail, so long as the same total threads
>> >> are created.
>> >> Whether threads are created all at once intially, or as their rampUp
>> >> delay expires, makes no overall difference to the running of the test.
>> >>
>> >> In the first case, the thread creation overhead is done at the start,
>> >> and in the onDemand case, the overhead is spread out over the full
>> >> rampUp time.
>> >>
>> >> For a short ramp-up time, it's probably better to create the threads
>> >> upfront; for a long ramp-up time it's likely to be better to create
>> >> threads as they become eligible to run.
>> >>
>> >> So another approach would be to automatically change the behaviour of
>> >> thread creation depending on the number of threads and total ramp-up
>> >> time.
>> >> However, getting the algorithm correct is not going to be easy, so the
>> >> simple solution is for the user to make the choice via a checkbox.
>> >>
>> >> >> So I find it Ok to create a new Test Element, but as it's how I build
>> >> it,
>> >> >> it's regular I agree with myself :-)
>> >> >>
>> >> >> But if you want to change things, go ahead as I am not sure to
>> >> understand
>> >> >> how you want to change it.
>> >> >
>> >> > I don't know yet how I would change it.
>> >> > I'll let the list know later.
>> >> >
>> >> >> Regards
>> >> >> Philippe
>> >> >>
>> >> >> On Sat, Jul 14, 2012 at 12:57 PM, sebb <se...@gmail.com> wrote:
>> >> >>
>> >> >>> On 14 July 2012 09:18, Philippe Mouawad <philippe.mouawad@gmail.com
>> >
>> >> >>> wrote:
>> >> >>> > Hello Sebb ,
>> >> >>> > I saw 3 reasons which Led me to implementing it this way:
>> >> >>> > - looking at use case of this feature it seems to me it's
>> different
>> >> from
>> >> >>> > current thread group and you might want to mix the 2 behaviours in
>> >> one
>> >> >>> test
>> >> >>> > plan. For me typical usage of on demand Will be to put lot of
>> >> threads and
>> >> >>> > very few iterations , maybe only one
>> >> >>>
>> >> >>> As far as I can tell, that does not require a separate test element.
>> >> >>>
>> >> >>> > - code of thread group would have been too complex
>> >> >>> > - currently thread group is not Much impacted and we can improve
>> on
>> >> >>> demand
>> >> >>> > Without risks on existing plans.
>> >> >>>
>> >> >>> It may well have made updates somewhat simpler; depends on how the
>> >> >>> combined thread group was implemented.
>> >> >>>
>> >> >>> But is it worth the inconvenience to end users?
>> >> >>> It's currently not at all easy to convert between the two styles of
>> >> >>> thread group.
>> >> >>>
>> >> >>> I think we need to look again at how the code could be rearranged;
>> it
>> >> >>> might be possible to have the best of both worlds.
>> >> >>> Possibly using something like the approach used for the HTTP
>> Sampler.
>> >> >>> If we can keep the same test plan classes, we can add new
>> >> >>> implementation classes if necessary without breaking test plans.
>> >> >>>
>> >> >>> > Regards
>> >> >>> > Philippe
>> >> >>> >
>> >> >>> >
>> >> >>> > On Saturday, July 14, 2012, sebb wrote:
>> >> >>> >
>> >> >>> >> I think it's good that the functionality of the onDemand thread
>> >> group
>> >> >>> >> now exists.
>> >> >>> >>
>> >> >>> >> I just wonder why it was not done as an option on the existing
>> >> thread
>> >> >>> >> group?
>> >> >>> >>
>> >> >>> >> Seems to me that would be simpler - and also easier to convert
>> >> >>> >> existing test plans if required (or indeed convert back).
>> >> >>> >>
>> >> >>> >> Is there a reason why the functionality has to be done as a
>> separate
>> >> >>> >> class, or could the code be incorporated into the existing thread
>> >> >>> >> group?
>> >> >>> >>
>> >> >>> >
>> >> >>> >
>> >> >>> > --
>> >> >>> > Cordialement.
>> >> >>> > Philippe Mouawad.
>> >> >>>
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Cordialement.
>> >> >> Philippe Mouawad.
>> >>
>> >
>> >
>> >
>> > --
>> > Cordialement.
>> > Philippe Mouawad.
>>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.

Re: OnDemand thread group

[Philippe Mouawad <ph...@gmail.com>]

Ok , I agree on what you say on alternate implementation.

But Regarding what you said previously:
"The current fix does not actually address that issue."

I don't understand ? Why and if not which issue is not addressed ?
Can you in this case clarify what Kirk Pepperdine meant ?

Thanks
Regards
Philippe

On Sat, Jul 14, 2012 at 6:24 PM, sebb <se...@gmail.com> wrote:

> On 14 July 2012 17:04, Philippe Mouawad <ph...@gmail.com>
> wrote:
> > Hello,
> > I understand it differently, what this feature does is that it enables
> > creation of thousands of short lived threads while doing so with current
> > implementation didn't enable this.
>
> Yes, that is also true. I should have mentioned that.
>
> However, this only applies if the threads are relatively short-lived
> compared with the total run-time.
>
> > With Thread Group, to create 10000 threads that run 1 HTTP requests ,
> will
> > make JMeter create 10000 threads at Test startup before sampling, so we
> > will have 10000 threads on first sample, this will require many resources
> > and will impact behaviour.
> > With On Demand Thread Group there is a big chance that many thread end
> and
> > that at a one point in Test we have far less running threads than 10000.
> > In my tests I see this behaviour.
> >
> > But maybe I am wrong.
>
> No, but I still don't see it as a fundamentally different type of thread
> group.
>
> I see it as an alternate implementation which is better suited to some
> test scenarios.
>
> Changing the thread count and ramp-up of an existing test plan may
> well require the changing the startup strategy.
> This is currently very awkward to do.
>
> > Regards
> > Philippe
> >
> > On Sat, Jul 14, 2012 at 5:54 PM, sebb <se...@gmail.com> wrote:
> >
> >> On 14 July 2012 15:39, sebb <se...@gmail.com> wrote:
> >> > On 14 July 2012 14:19, Philippe Mouawad <ph...@gmail.com>
> >> wrote:
> >> >> Hello Sebb,
> >> >> I am not sure we shoud use the approach of Http Sampler.
> >> >> Because for example a future enhancement I see to OnDemandThreadGroup
> >> is to
> >> >> add Thread Pooling, and in this case user will input the min/max
> size of
> >> >> the pool.
> >> >> In this case the HttpSampler approach won't fit unless user inputs
> >> >> configuration in jmeter.properties.
> >> >
> >> > Why not? Surely we can just add the extra fields to the GUI?
> >> > Or perhaps I'm missing something.
> >> >
> >> >> I don't see why introducing a new Test Element is a problem.
> >> >
> >> > More to document; more documentation for users to read.
> >> >
> >> > At present, the thread groups GUIs are identical apart from the name.
> >> > Much easier to support this via an additional checkbox.
> >> >
> >> >> And why would users want to convert thread group to new one ?
> >> >
> >> > Because they would like to use the new feature with existing tests.
> >> >
> >> >> Another point I have in mind is existing plugins that extend
> >> >> AbstractThreadGroup, are you sure we won't break them with this
> >> approach ?
> >> >
> >> > That's a separate issue.
> >> >
> >> >> In my understanding, this Test Element answers a new kind of Test
> case
> >> if
> >> >
> >> > It's not so different that it requires a new GUI, unlike the setUp and
> >> > tearDown thread groups.
> >> >
> >> >> you remember what Kirk Pepperdine was saying in initial
> conversation:*
> >> >> "However, I'm often simulating open systems which means I do not want
> >> rate
> >> >> of entry into the system to be controlled by the performance of the
> >> system
> >> >> (rate of exit). "*
> >>
> >> The current fix does not actually address that issue.
> >>
> >> Thinking about it further, it seems to me that when the threads are
> >> created is an implementation detail, so long as the same total threads
> >> are created.
> >> Whether threads are created all at once intially, or as their rampUp
> >> delay expires, makes no overall difference to the running of the test.
> >>
> >> In the first case, the thread creation overhead is done at the start,
> >> and in the onDemand case, the overhead is spread out over the full
> >> rampUp time.
> >>
> >> For a short ramp-up time, it's probably better to create the threads
> >> upfront; for a long ramp-up time it's likely to be better to create
> >> threads as they become eligible to run.
> >>
> >> So another approach would be to automatically change the behaviour of
> >> thread creation depending on the number of threads and total ramp-up
> >> time.
> >> However, getting the algorithm correct is not going to be easy, so the
> >> simple solution is for the user to make the choice via a checkbox.
> >>
> >> >> So I find it Ok to create a new Test Element, but as it's how I build
> >> it,
> >> >> it's regular I agree with myself :-)
> >> >>
> >> >> But if you want to change things, go ahead as I am not sure to
> >> understand
> >> >> how you want to change it.
> >> >
> >> > I don't know yet how I would change it.
> >> > I'll let the list know later.
> >> >
> >> >> Regards
> >> >> Philippe
> >> >>
> >> >> On Sat, Jul 14, 2012 at 12:57 PM, sebb <se...@gmail.com> wrote:
> >> >>
> >> >>> On 14 July 2012 09:18, Philippe Mouawad <philippe.mouawad@gmail.com
> >
> >> >>> wrote:
> >> >>> > Hello Sebb ,
> >> >>> > I saw 3 reasons which Led me to implementing it this way:
> >> >>> > - looking at use case of this feature it seems to me it's
> different
> >> from
> >> >>> > current thread group and you might want to mix the 2 behaviours in
> >> one
> >> >>> test
> >> >>> > plan. For me typical usage of on demand Will be to put lot of
> >> threads and
> >> >>> > very few iterations , maybe only one
> >> >>>
> >> >>> As far as I can tell, that does not require a separate test element.
> >> >>>
> >> >>> > - code of thread group would have been too complex
> >> >>> > - currently thread group is not Much impacted and we can improve
> on
> >> >>> demand
> >> >>> > Without risks on existing plans.
> >> >>>
> >> >>> It may well have made updates somewhat simpler; depends on how the
> >> >>> combined thread group was implemented.
> >> >>>
> >> >>> But is it worth the inconvenience to end users?
> >> >>> It's currently not at all easy to convert between the two styles of
> >> >>> thread group.
> >> >>>
> >> >>> I think we need to look again at how the code could be rearranged;
> it
> >> >>> might be possible to have the best of both worlds.
> >> >>> Possibly using something like the approach used for the HTTP
> Sampler.
> >> >>> If we can keep the same test plan classes, we can add new
> >> >>> implementation classes if necessary without breaking test plans.
> >> >>>
> >> >>> > Regards
> >> >>> > Philippe
> >> >>> >
> >> >>> >
> >> >>> > On Saturday, July 14, 2012, sebb wrote:
> >> >>> >
> >> >>> >> I think it's good that the functionality of the onDemand thread
> >> group
> >> >>> >> now exists.
> >> >>> >>
> >> >>> >> I just wonder why it was not done as an option on the existing
> >> thread
> >> >>> >> group?
> >> >>> >>
> >> >>> >> Seems to me that would be simpler - and also easier to convert
> >> >>> >> existing test plans if required (or indeed convert back).
> >> >>> >>
> >> >>> >> Is there a reason why the functionality has to be done as a
> separate
> >> >>> >> class, or could the code be incorporated into the existing thread
> >> >>> >> group?
> >> >>> >>
> >> >>> >
> >> >>> >
> >> >>> > --
> >> >>> > Cordialement.
> >> >>> > Philippe Mouawad.
> >> >>>
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Cordialement.
> >> >> Philippe Mouawad.
> >>
> >
> >
> >
> > --
> > Cordialement.
> > Philippe Mouawad.
>



-- 
Cordialement.
Philippe Mouawad.

Re: OnDemand thread group

[sebb <se...@gmail.com>]

On 14 July 2012 17:04, Philippe Mouawad <ph...@gmail.com> wrote:
> Hello,
> I understand it differently, what this feature does is that it enables
> creation of thousands of short lived threads while doing so with current
> implementation didn't enable this.

Yes, that is also true. I should have mentioned that.

However, this only applies if the threads are relatively short-lived
compared with the total run-time.

> With Thread Group, to create 10000 threads that run 1 HTTP requests , will
> make JMeter create 10000 threads at Test startup before sampling, so we
> will have 10000 threads on first sample, this will require many resources
> and will impact behaviour.
> With On Demand Thread Group there is a big chance that many thread end and
> that at a one point in Test we have far less running threads than 10000.
> In my tests I see this behaviour.
>
> But maybe I am wrong.

No, but I still don't see it as a fundamentally different type of thread group.

I see it as an alternate implementation which is better suited to some
test scenarios.

Changing the thread count and ramp-up of an existing test plan may
well require the changing the startup strategy.
This is currently very awkward to do.

> Regards
> Philippe
>
> On Sat, Jul 14, 2012 at 5:54 PM, sebb <se...@gmail.com> wrote:
>
>> On 14 July 2012 15:39, sebb <se...@gmail.com> wrote:
>> > On 14 July 2012 14:19, Philippe Mouawad <ph...@gmail.com>
>> wrote:
>> >> Hello Sebb,
>> >> I am not sure we shoud use the approach of Http Sampler.
>> >> Because for example a future enhancement I see to OnDemandThreadGroup
>> is to
>> >> add Thread Pooling, and in this case user will input the min/max size of
>> >> the pool.
>> >> In this case the HttpSampler approach won't fit unless user inputs
>> >> configuration in jmeter.properties.
>> >
>> > Why not? Surely we can just add the extra fields to the GUI?
>> > Or perhaps I'm missing something.
>> >
>> >> I don't see why introducing a new Test Element is a problem.
>> >
>> > More to document; more documentation for users to read.
>> >
>> > At present, the thread groups GUIs are identical apart from the name.
>> > Much easier to support this via an additional checkbox.
>> >
>> >> And why would users want to convert thread group to new one ?
>> >
>> > Because they would like to use the new feature with existing tests.
>> >
>> >> Another point I have in mind is existing plugins that extend
>> >> AbstractThreadGroup, are you sure we won't break them with this
>> approach ?
>> >
>> > That's a separate issue.
>> >
>> >> In my understanding, this Test Element answers a new kind of Test case
>> if
>> >
>> > It's not so different that it requires a new GUI, unlike the setUp and
>> > tearDown thread groups.
>> >
>> >> you remember what Kirk Pepperdine was saying in initial conversation:*
>> >> "However, I'm often simulating open systems which means I do not want
>> rate
>> >> of entry into the system to be controlled by the performance of the
>> system
>> >> (rate of exit). "*
>>
>> The current fix does not actually address that issue.
>>
>> Thinking about it further, it seems to me that when the threads are
>> created is an implementation detail, so long as the same total threads
>> are created.
>> Whether threads are created all at once intially, or as their rampUp
>> delay expires, makes no overall difference to the running of the test.
>>
>> In the first case, the thread creation overhead is done at the start,
>> and in the onDemand case, the overhead is spread out over the full
>> rampUp time.
>>
>> For a short ramp-up time, it's probably better to create the threads
>> upfront; for a long ramp-up time it's likely to be better to create
>> threads as they become eligible to run.
>>
>> So another approach would be to automatically change the behaviour of
>> thread creation depending on the number of threads and total ramp-up
>> time.
>> However, getting the algorithm correct is not going to be easy, so the
>> simple solution is for the user to make the choice via a checkbox.
>>
>> >> So I find it Ok to create a new Test Element, but as it's how I build
>> it,
>> >> it's regular I agree with myself :-)
>> >>
>> >> But if you want to change things, go ahead as I am not sure to
>> understand
>> >> how you want to change it.
>> >
>> > I don't know yet how I would change it.
>> > I'll let the list know later.
>> >
>> >> Regards
>> >> Philippe
>> >>
>> >> On Sat, Jul 14, 2012 at 12:57 PM, sebb <se...@gmail.com> wrote:
>> >>
>> >>> On 14 July 2012 09:18, Philippe Mouawad <ph...@gmail.com>
>> >>> wrote:
>> >>> > Hello Sebb ,
>> >>> > I saw 3 reasons which Led me to implementing it this way:
>> >>> > - looking at use case of this feature it seems to me it's different
>> from
>> >>> > current thread group and you might want to mix the 2 behaviours in
>> one
>> >>> test
>> >>> > plan. For me typical usage of on demand Will be to put lot of
>> threads and
>> >>> > very few iterations , maybe only one
>> >>>
>> >>> As far as I can tell, that does not require a separate test element.
>> >>>
>> >>> > - code of thread group would have been too complex
>> >>> > - currently thread group is not Much impacted and we can improve on
>> >>> demand
>> >>> > Without risks on existing plans.
>> >>>
>> >>> It may well have made updates somewhat simpler; depends on how the
>> >>> combined thread group was implemented.
>> >>>
>> >>> But is it worth the inconvenience to end users?
>> >>> It's currently not at all easy to convert between the two styles of
>> >>> thread group.
>> >>>
>> >>> I think we need to look again at how the code could be rearranged; it
>> >>> might be possible to have the best of both worlds.
>> >>> Possibly using something like the approach used for the HTTP Sampler.
>> >>> If we can keep the same test plan classes, we can add new
>> >>> implementation classes if necessary without breaking test plans.
>> >>>
>> >>> > Regards
>> >>> > Philippe
>> >>> >
>> >>> >
>> >>> > On Saturday, July 14, 2012, sebb wrote:
>> >>> >
>> >>> >> I think it's good that the functionality of the onDemand thread
>> group
>> >>> >> now exists.
>> >>> >>
>> >>> >> I just wonder why it was not done as an option on the existing
>> thread
>> >>> >> group?
>> >>> >>
>> >>> >> Seems to me that would be simpler - and also easier to convert
>> >>> >> existing test plans if required (or indeed convert back).
>> >>> >>
>> >>> >> Is there a reason why the functionality has to be done as a separate
>> >>> >> class, or could the code be incorporated into the existing thread
>> >>> >> group?
>> >>> >>
>> >>> >
>> >>> >
>> >>> > --
>> >>> > Cordialement.
>> >>> > Philippe Mouawad.
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> Cordialement.
>> >> Philippe Mouawad.
>>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.

Re: OnDemand thread group

[Philippe Mouawad <ph...@gmail.com>]

Hello,
I understand it differently, what this feature does is that it enables
creation of thousands of short lived threads while doing so with current
implementation didn't enable this.

With Thread Group, to create 10000 threads that run 1 HTTP requests , will
make JMeter create 10000 threads at Test startup before sampling, so we
will have 10000 threads on first sample, this will require many resources
and will impact behaviour.
With On Demand Thread Group there is a big chance that many thread end and
that at a one point in Test we have far less running threads than 10000.
In my tests I see this behaviour.

But maybe I am wrong.

Regards
Philippe

On Sat, Jul 14, 2012 at 5:54 PM, sebb <se...@gmail.com> wrote:

> On 14 July 2012 15:39, sebb <se...@gmail.com> wrote:
> > On 14 July 2012 14:19, Philippe Mouawad <ph...@gmail.com>
> wrote:
> >> Hello Sebb,
> >> I am not sure we shoud use the approach of Http Sampler.
> >> Because for example a future enhancement I see to OnDemandThreadGroup
> is to
> >> add Thread Pooling, and in this case user will input the min/max size of
> >> the pool.
> >> In this case the HttpSampler approach won't fit unless user inputs
> >> configuration in jmeter.properties.
> >
> > Why not? Surely we can just add the extra fields to the GUI?
> > Or perhaps I'm missing something.
> >
> >> I don't see why introducing a new Test Element is a problem.
> >
> > More to document; more documentation for users to read.
> >
> > At present, the thread groups GUIs are identical apart from the name.
> > Much easier to support this via an additional checkbox.
> >
> >> And why would users want to convert thread group to new one ?
> >
> > Because they would like to use the new feature with existing tests.
> >
> >> Another point I have in mind is existing plugins that extend
> >> AbstractThreadGroup, are you sure we won't break them with this
> approach ?
> >
> > That's a separate issue.
> >
> >> In my understanding, this Test Element answers a new kind of Test case
> if
> >
> > It's not so different that it requires a new GUI, unlike the setUp and
> > tearDown thread groups.
> >
> >> you remember what Kirk Pepperdine was saying in initial conversation:*
> >> "However, I'm often simulating open systems which means I do not want
> rate
> >> of entry into the system to be controlled by the performance of the
> system
> >> (rate of exit). "*
>
> The current fix does not actually address that issue.
>
> Thinking about it further, it seems to me that when the threads are
> created is an implementation detail, so long as the same total threads
> are created.
> Whether threads are created all at once intially, or as their rampUp
> delay expires, makes no overall difference to the running of the test.
>
> In the first case, the thread creation overhead is done at the start,
> and in the onDemand case, the overhead is spread out over the full
> rampUp time.
>
> For a short ramp-up time, it's probably better to create the threads
> upfront; for a long ramp-up time it's likely to be better to create
> threads as they become eligible to run.
>
> So another approach would be to automatically change the behaviour of
> thread creation depending on the number of threads and total ramp-up
> time.
> However, getting the algorithm correct is not going to be easy, so the
> simple solution is for the user to make the choice via a checkbox.
>
> >> So I find it Ok to create a new Test Element, but as it's how I build
> it,
> >> it's regular I agree with myself :-)
> >>
> >> But if you want to change things, go ahead as I am not sure to
> understand
> >> how you want to change it.
> >
> > I don't know yet how I would change it.
> > I'll let the list know later.
> >
> >> Regards
> >> Philippe
> >>
> >> On Sat, Jul 14, 2012 at 12:57 PM, sebb <se...@gmail.com> wrote:
> >>
> >>> On 14 July 2012 09:18, Philippe Mouawad <ph...@gmail.com>
> >>> wrote:
> >>> > Hello Sebb ,
> >>> > I saw 3 reasons which Led me to implementing it this way:
> >>> > - looking at use case of this feature it seems to me it's different
> from
> >>> > current thread group and you might want to mix the 2 behaviours in
> one
> >>> test
> >>> > plan. For me typical usage of on demand Will be to put lot of
> threads and
> >>> > very few iterations , maybe only one
> >>>
> >>> As far as I can tell, that does not require a separate test element.
> >>>
> >>> > - code of thread group would have been too complex
> >>> > - currently thread group is not Much impacted and we can improve on
> >>> demand
> >>> > Without risks on existing plans.
> >>>
> >>> It may well have made updates somewhat simpler; depends on how the
> >>> combined thread group was implemented.
> >>>
> >>> But is it worth the inconvenience to end users?
> >>> It's currently not at all easy to convert between the two styles of
> >>> thread group.
> >>>
> >>> I think we need to look again at how the code could be rearranged; it
> >>> might be possible to have the best of both worlds.
> >>> Possibly using something like the approach used for the HTTP Sampler.
> >>> If we can keep the same test plan classes, we can add new
> >>> implementation classes if necessary without breaking test plans.
> >>>
> >>> > Regards
> >>> > Philippe
> >>> >
> >>> >
> >>> > On Saturday, July 14, 2012, sebb wrote:
> >>> >
> >>> >> I think it's good that the functionality of the onDemand thread
> group
> >>> >> now exists.
> >>> >>
> >>> >> I just wonder why it was not done as an option on the existing
> thread
> >>> >> group?
> >>> >>
> >>> >> Seems to me that would be simpler - and also easier to convert
> >>> >> existing test plans if required (or indeed convert back).
> >>> >>
> >>> >> Is there a reason why the functionality has to be done as a separate
> >>> >> class, or could the code be incorporated into the existing thread
> >>> >> group?
> >>> >>
> >>> >
> >>> >
> >>> > --
> >>> > Cordialement.
> >>> > Philippe Mouawad.
> >>>
> >>
> >>
> >>
> >> --
> >> Cordialement.
> >> Philippe Mouawad.
>



-- 
Cordialement.
Philippe Mouawad.

Re: OnDemand thread group

[sebb <se...@gmail.com>]

On 14 July 2012 15:39, sebb <se...@gmail.com> wrote:
> On 14 July 2012 14:19, Philippe Mouawad <ph...@gmail.com> wrote:
>> Hello Sebb,
>> I am not sure we shoud use the approach of Http Sampler.
>> Because for example a future enhancement I see to OnDemandThreadGroup is to
>> add Thread Pooling, and in this case user will input the min/max size of
>> the pool.
>> In this case the HttpSampler approach won't fit unless user inputs
>> configuration in jmeter.properties.
>
> Why not? Surely we can just add the extra fields to the GUI?
> Or perhaps I'm missing something.
>
>> I don't see why introducing a new Test Element is a problem.
>
> More to document; more documentation for users to read.
>
> At present, the thread groups GUIs are identical apart from the name.
> Much easier to support this via an additional checkbox.
>
>> And why would users want to convert thread group to new one ?
>
> Because they would like to use the new feature with existing tests.
>
>> Another point I have in mind is existing plugins that extend
>> AbstractThreadGroup, are you sure we won't break them with this approach ?
>
> That's a separate issue.
>
>> In my understanding, this Test Element answers a new kind of Test case if
>
> It's not so different that it requires a new GUI, unlike the setUp and
> tearDown thread groups.
>
>> you remember what Kirk Pepperdine was saying in initial conversation:*
>> "However, I'm often simulating open systems which means I do not want rate
>> of entry into the system to be controlled by the performance of the system
>> (rate of exit). "*

The current fix does not actually address that issue.

Thinking about it further, it seems to me that when the threads are
created is an implementation detail, so long as the same total threads
are created.
Whether threads are created all at once intially, or as their rampUp
delay expires, makes no overall difference to the running of the test.

In the first case, the thread creation overhead is done at the start,
and in the onDemand case, the overhead is spread out over the full
rampUp time.

For a short ramp-up time, it's probably better to create the threads
upfront; for a long ramp-up time it's likely to be better to create
threads as they become eligible to run.

So another approach would be to automatically change the behaviour of
thread creation depending on the number of threads and total ramp-up
time.
However, getting the algorithm correct is not going to be easy, so the
simple solution is for the user to make the choice via a checkbox.

>> So I find it Ok to create a new Test Element, but as it's how I build it,
>> it's regular I agree with myself :-)
>>
>> But if you want to change things, go ahead as I am not sure to understand
>> how you want to change it.
>
> I don't know yet how I would change it.
> I'll let the list know later.
>
>> Regards
>> Philippe
>>
>> On Sat, Jul 14, 2012 at 12:57 PM, sebb <se...@gmail.com> wrote:
>>
>>> On 14 July 2012 09:18, Philippe Mouawad <ph...@gmail.com>
>>> wrote:
>>> > Hello Sebb ,
>>> > I saw 3 reasons which Led me to implementing it this way:
>>> > - looking at use case of this feature it seems to me it's different from
>>> > current thread group and you might want to mix the 2 behaviours in one
>>> test
>>> > plan. For me typical usage of on demand Will be to put lot of threads and
>>> > very few iterations , maybe only one
>>>
>>> As far as I can tell, that does not require a separate test element.
>>>
>>> > - code of thread group would have been too complex
>>> > - currently thread group is not Much impacted and we can improve on
>>> demand
>>> > Without risks on existing plans.
>>>
>>> It may well have made updates somewhat simpler; depends on how the
>>> combined thread group was implemented.
>>>
>>> But is it worth the inconvenience to end users?
>>> It's currently not at all easy to convert between the two styles of
>>> thread group.
>>>
>>> I think we need to look again at how the code could be rearranged; it
>>> might be possible to have the best of both worlds.
>>> Possibly using something like the approach used for the HTTP Sampler.
>>> If we can keep the same test plan classes, we can add new
>>> implementation classes if necessary without breaking test plans.
>>>
>>> > Regards
>>> > Philippe
>>> >
>>> >
>>> > On Saturday, July 14, 2012, sebb wrote:
>>> >
>>> >> I think it's good that the functionality of the onDemand thread group
>>> >> now exists.
>>> >>
>>> >> I just wonder why it was not done as an option on the existing thread
>>> >> group?
>>> >>
>>> >> Seems to me that would be simpler - and also easier to convert
>>> >> existing test plans if required (or indeed convert back).
>>> >>
>>> >> Is there a reason why the functionality has to be done as a separate
>>> >> class, or could the code be incorporated into the existing thread
>>> >> group?
>>> >>
>>> >
>>> >
>>> > --
>>> > Cordialement.
>>> > Philippe Mouawad.
>>>
>>
>>
>>
>> --
>> Cordialement.
>> Philippe Mouawad.

Re: OnDemand thread group

[sebb <se...@gmail.com>]

On 14 July 2012 14:19, Philippe Mouawad <ph...@gmail.com> wrote:
> Hello Sebb,
> I am not sure we shoud use the approach of Http Sampler.
> Because for example a future enhancement I see to OnDemandThreadGroup is to
> add Thread Pooling, and in this case user will input the min/max size of
> the pool.
> In this case the HttpSampler approach won't fit unless user inputs
> configuration in jmeter.properties.

Why not? Surely we can just add the extra fields to the GUI?
Or perhaps I'm missing something.

> I don't see why introducing a new Test Element is a problem.

More to document; more documentation for users to read.

At present, the thread groups GUIs are identical apart from the name.
Much easier to support this via an additional checkbox.

> And why would users want to convert thread group to new one ?

Because they would like to use the new feature with existing tests.

> Another point I have in mind is existing plugins that extend
> AbstractThreadGroup, are you sure we won't break them with this approach ?

That's a separate issue.

> In my understanding, this Test Element answers a new kind of Test case if

It's not so different that it requires a new GUI, unlike the setUp and
tearDown thread groups.

> you remember what Kirk Pepperdine was saying in initial conversation:*
> "However, I'm often simulating open systems which means I do not want rate
> of entry into the system to be controlled by the performance of the system
> (rate of exit). "*
> So I find it Ok to create a new Test Element, but as it's how I build it,
> it's regular I agree with myself :-)
>
> But if you want to change things, go ahead as I am not sure to understand
> how you want to change it.

I don't know yet how I would change it.
I'll let the list know later.

> Regards
> Philippe
>
> On Sat, Jul 14, 2012 at 12:57 PM, sebb <se...@gmail.com> wrote:
>
>> On 14 July 2012 09:18, Philippe Mouawad <ph...@gmail.com>
>> wrote:
>> > Hello Sebb ,
>> > I saw 3 reasons which Led me to implementing it this way:
>> > - looking at use case of this feature it seems to me it's different from
>> > current thread group and you might want to mix the 2 behaviours in one
>> test
>> > plan. For me typical usage of on demand Will be to put lot of threads and
>> > very few iterations , maybe only one
>>
>> As far as I can tell, that does not require a separate test element.
>>
>> > - code of thread group would have been too complex
>> > - currently thread group is not Much impacted and we can improve on
>> demand
>> > Without risks on existing plans.
>>
>> It may well have made updates somewhat simpler; depends on how the
>> combined thread group was implemented.
>>
>> But is it worth the inconvenience to end users?
>> It's currently not at all easy to convert between the two styles of
>> thread group.
>>
>> I think we need to look again at how the code could be rearranged; it
>> might be possible to have the best of both worlds.
>> Possibly using something like the approach used for the HTTP Sampler.
>> If we can keep the same test plan classes, we can add new
>> implementation classes if necessary without breaking test plans.
>>
>> > Regards
>> > Philippe
>> >
>> >
>> > On Saturday, July 14, 2012, sebb wrote:
>> >
>> >> I think it's good that the functionality of the onDemand thread group
>> >> now exists.
>> >>
>> >> I just wonder why it was not done as an option on the existing thread
>> >> group?
>> >>
>> >> Seems to me that would be simpler - and also easier to convert
>> >> existing test plans if required (or indeed convert back).
>> >>
>> >> Is there a reason why the functionality has to be done as a separate
>> >> class, or could the code be incorporated into the existing thread
>> >> group?
>> >>
>> >
>> >
>> > --
>> > Cordialement.
>> > Philippe Mouawad.
>>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.

Re: OnDemand thread group

[Philippe Mouawad <ph...@gmail.com>]

Hello Sebb,
I am not sure we shoud use the approach of Http Sampler.
Because for example a future enhancement I see to OnDemandThreadGroup is to
add Thread Pooling, and in this case user will input the min/max size of
the pool.
In this case the HttpSampler approach won't fit unless user inputs
configuration in jmeter.properties.

I don't see why introducing a new Test Element is a problem.
And why would users want to convert thread group to new one ?

Another point I have in mind is existing plugins that extend
AbstractThreadGroup, are you sure we won't break them with this approach ?

In my understanding, this Test Element answers a new kind of Test case if
you remember what Kirk Pepperdine was saying in initial conversation:*
"However, I'm often simulating open systems which means I do not want rate
of entry into the system to be controlled by the performance of the system
(rate of exit). "*
So I find it Ok to create a new Test Element, but as it's how I build it,
it's regular I agree with myself :-)

But if you want to change things, go ahead as I am not sure to understand
how you want to change it.

Regards
Philippe

On Sat, Jul 14, 2012 at 12:57 PM, sebb <se...@gmail.com> wrote:

> On 14 July 2012 09:18, Philippe Mouawad <ph...@gmail.com>
> wrote:
> > Hello Sebb ,
> > I saw 3 reasons which Led me to implementing it this way:
> > - looking at use case of this feature it seems to me it's different from
> > current thread group and you might want to mix the 2 behaviours in one
> test
> > plan. For me typical usage of on demand Will be to put lot of threads and
> > very few iterations , maybe only one
>
> As far as I can tell, that does not require a separate test element.
>
> > - code of thread group would have been too complex
> > - currently thread group is not Much impacted and we can improve on
> demand
> > Without risks on existing plans.
>
> It may well have made updates somewhat simpler; depends on how the
> combined thread group was implemented.
>
> But is it worth the inconvenience to end users?
> It's currently not at all easy to convert between the two styles of
> thread group.
>
> I think we need to look again at how the code could be rearranged; it
> might be possible to have the best of both worlds.
> Possibly using something like the approach used for the HTTP Sampler.
> If we can keep the same test plan classes, we can add new
> implementation classes if necessary without breaking test plans.
>
> > Regards
> > Philippe
> >
> >
> > On Saturday, July 14, 2012, sebb wrote:
> >
> >> I think it's good that the functionality of the onDemand thread group
> >> now exists.
> >>
> >> I just wonder why it was not done as an option on the existing thread
> >> group?
> >>
> >> Seems to me that would be simpler - and also easier to convert
> >> existing test plans if required (or indeed convert back).
> >>
> >> Is there a reason why the functionality has to be done as a separate
> >> class, or could the code be incorporated into the existing thread
> >> group?
> >>
> >
> >
> > --
> > Cordialement.
> > Philippe Mouawad.
>



-- 
Cordialement.
Philippe Mouawad.

Re: OnDemand thread group

[sebb <se...@gmail.com>]

On 14 July 2012 09:18, Philippe Mouawad <ph...@gmail.com> wrote:
> Hello Sebb ,
> I saw 3 reasons which Led me to implementing it this way:
> - looking at use case of this feature it seems to me it's different from
> current thread group and you might want to mix the 2 behaviours in one test
> plan. For me typical usage of on demand Will be to put lot of threads and
> very few iterations , maybe only one

As far as I can tell, that does not require a separate test element.

> - code of thread group would have been too complex
> - currently thread group is not Much impacted and we can improve on demand
> Without risks on existing plans.

It may well have made updates somewhat simpler; depends on how the
combined thread group was implemented.

But is it worth the inconvenience to end users?
It's currently not at all easy to convert between the two styles of
thread group.

I think we need to look again at how the code could be rearranged; it
might be possible to have the best of both worlds.
Possibly using something like the approach used for the HTTP Sampler.
If we can keep the same test plan classes, we can add new
implementation classes if necessary without breaking test plans.

> Regards
> Philippe
>
>
> On Saturday, July 14, 2012, sebb wrote:
>
>> I think it's good that the functionality of the onDemand thread group
>> now exists.
>>
>> I just wonder why it was not done as an option on the existing thread
>> group?
>>
>> Seems to me that would be simpler - and also easier to convert
>> existing test plans if required (or indeed convert back).
>>
>> Is there a reason why the functionality has to be done as a separate
>> class, or could the code be incorporated into the existing thread
>> group?
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.

Re: OnDemand thread group

[Philippe Mouawad <ph...@gmail.com>]

Hello Sebb ,
I saw 3 reasons which Led me to implementing it this way:
- looking at use case of this feature it seems to me it's different from
current thread group and you might want to mix the 2 behaviours in one test
plan. For me typical usage of on demand Will be to put lot of threads and
very few iterations , maybe only one
- code of thread group would have been too complex
- currently thread group is not Much impacted and we can improve on demand
Without risks on existing plans.

Regards
Philippe


On Saturday, July 14, 2012, sebb wrote:

> I think it's good that the functionality of the onDemand thread group
> now exists.
>
> I just wonder why it was not done as an option on the existing thread
> group?
>
> Seems to me that would be simpler - and also easier to convert
> existing test plans if required (or indeed convert back).
>
> Is there a reason why the functionality has to be done as a separate
> class, or could the code be incorporated into the existing thread
> group?
>


-- 
Cordialement.
Philippe Mouawad.