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 18:52:33 GMT
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 ?

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