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 15:54:03 GMT
On 14 July 2012 15:39, sebb <sebbaz@gmail.com> wrote:
> 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). "*

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 <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