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 23:40:29 GMT
On 14 July 2012 19:52, Philippe Mouawad <philippe.mouawad@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 <sebbaz@gmail.com> wrote:
>
>> On 14 July 2012 17:04, Philippe Mouawad <philippe.mouawad@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 <sebbaz@gmail.com> wrote:
>> >
>> >> 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.
>> >>
>> >
>> >
>> >
>> > --
>> > Cordialement.
>> > Philippe Mouawad.
>>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.

Mime
View raw message