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 16:24:40 GMT
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.

Mime
View raw message