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 16:04:18 GMT
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.

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.

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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message