jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: OnDemand thread group
Date Sat, 14 Jul 2012 14:39:54 GMT
On 14 July 2012 14:19, Philippe Mouawad <philippe.mouawad@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 <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
View raw message