jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <philippe.moua...@gmail.com>
Subject Re: OnDemand thread group
Date Sat, 14 Jul 2012 13:19:11 GMT
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 <sebbaz@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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message