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.
