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 <[email protected]> wrote: > On 14 July 2012 17:04, Philippe Mouawad <[email protected]> > 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 <[email protected]> wrote: > > > >> On 14 July 2012 15:39, sebb <[email protected]> wrote: > >> > On 14 July 2012 14:19, Philippe Mouawad <[email protected]> > >> 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 <[email protected]> wrote: > >> >> > >> >>> On 14 July 2012 09:18, Philippe Mouawad <[email protected] > > > >> >>> 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.
