Hi Philippe, Just got back from vacation going through email and I noticed that I missed this one. So I've now downloaded the nightly build and loaded a test plan to check it out. Unfortunately the benchmark I decided to setup and run against is borked. Well, I don't know if JMeter is the source of the problem my recent upgrade to Mountain Lion (and what it did to Java). I'll retry on an older machine where the bench should still behave as expected and then see how this new ThreadGroup functions. My guess is that it should be ok as it didn't complain as it would have using a regular ThreadGroup. However, I would like to run a much much longer test to make sure. I'll report back once this is done.
Regards, Kirk On 2012-07-14, at 3:36 PM, Philippe Mouawad <[email protected]> wrote: > Hello, > Just a little mail to inform you that this feature has been implemented as > part of: > https://issues.apache.org/bugzilla/show_bug.cgi?id=53418 > It is currently available in nightly build: > http://ci.apache.org/projects/jmeter/nightlies/ > > @Kirk, it would be nice from you to look at this feature to see if it answers > your initial request and give us some feedback. > > Note that this feature may be subject to changes until next release, but > getting some feedback would be very useful. > > > Regards > Philippe M. > > On Sun, Jun 17, 2012 at 9:06 PM, sebb <[email protected]> wrote: > On 17 June 2012 13:57, Flavio Cysne <[email protected]> wrote: > > Post entry in my blog: > > http://flaviocysne.blogspot.com.br/2012/06/how-to-dynamically-increasedecrease.html > > > > It's an unfinished work, but it's suffice to make what is proposed. > > Comments and constructive criticism are welcome. > > Thanks! > > The property used to control the thread count can also be set using > the BeanShell server, see: > > http://jmeter.apache.org/usermanual/best-practices.html#beanshell_server > > Or since properties are global, you could run the property update > sampler ("load controller") in a separate parallel thread group with > one thread. > > However, JMeter will still have to start all the threads - even if > they are not actively sampling - which will take up memory. > > It may not be too hard to change JMeter so it delays the thread > creation until required. > That may help in some use cases. > > But it would probably be somewhat harder to allow threads to be > created later on demand. > And converting to an event-based model is definitely a lot of work. > > > Hope it helps you. > > Flávio Cysne > > > > 2012/6/15 Flavio Cysne <[email protected]> > > > >> Errata: > >> > >> The first "If Controller" is executed and update a property named > >> "currentThreads" ... > >> > >> > >> 2012/6/15 Flavio Cysne <[email protected]> > >> > >>> I have tested something in JMeter that could achieve a dynamic threading > >>> model and there was no need of new implementations. > >>> > >>> Basically, I have this structure: > >>> > >>> 1. Test Plan: { variables : [ {name: "maxThreads", value: 5}, {name: > >>> "currentThreads", value: 1} ] } > >>> 2. | - Thread Group: { threads: "${maxThreads}", rampup: 0, infinite: > >>> true } > >>> 3. | - If Controller: { condition: "(${__threadNum()} === > >>> ${maxThreads})" } > >>> 4. | - Sampler /* I've used HTTP Request, but anyone would be > >>> used */ > >>> 5. | - RegEx Extractor: {refName: "threads", expression: > >>> "(.*)", model: "$1$", matchNo: "1", defaultValue: "0"} > >>> 6. | - BeanShell Post-Processor: {language: "javascript", > >>> script: "var threads = vars.get(\"threads\");\nprops.put(\"currentThreads > >>> \",threads);"} > >>> 7. | - If Controller: { condition: "(${__threadNum()} < > >>> ${maxThreads})" } > >>> 8. | - If Controller: { condition: "(${__threadNum()} <= ${__P( > >>> currentThreads,0)})" } > >>> 9. | - All other Samplers go here > >>> > >>> > >>> The idea is starting the maximum number of desired threads at the > >>> beginning but only use what you want. > >>> The first "If Controller" is executed and update a property named > >>> "threads" with the value retrieved from a response (HTTP, SOAP, file, > >>> whatever JMeter can access) > >>> When the first loop iteration is done line 9 will be skipped because > >>> ${__P(currentThreads,0)} will return 0. At the same iteration, lines 4 > >>> through 6 will be executed and will update the "currentThreads" property > >>> using the value in "threads" variable. > >>> After the first iteration, if the "currentThreads" property has been > >>> updated, line 9 will be executed using only the number of threads > >>> of "currentThreads" property. > >>> To increase/decrease the "currentThreads" property all you have to do is > >>> edit the file accessed by the Sampler at line 4 and wait for the next > >>> iteration to see the new "threading model" running. > >>> > >>> The approach used by distributed testing and this pseudo-dynamic > >>> threading model will include ${__machineName()} or ${__machineIP()} in "If > >>> Controller" conditions. > >>> > >>> I'll try to make a entry in my blog to explain in detail this scenario. > >>> > >>> I used JMeter 2.7 and you can download jmx file > >>> here<https://docs.google.com/open?id=0Bwr5j-BqUUDobnFTSHc1eTltdmM> > >>> . > >>> > >>> Hope it helps you. > >>> Flávio Cysne > >>> > >>> 2012/6/15 D G <[email protected]> > >>> > >>>> Details are very welcome as I'm still not sure whether I fully > >>>> understand the problem :) > >>>> > >>>> Thread pooling does sound nice and it might enable a feature I'd like: > >>>> > >>>> On-demand creation of threads. Say you're looping 10 threads, system > >>>> is under no load. > >>>> Currently: if you want 10 more users you need to stop the test, add 10 > >>>> users and start it again. > >>>> > >>>> It would be nice if it where possible to simply say '+10', followed by > >>>> some monitoring and then another '+10' (30 threads running total) etc. > >>>> (10 is an example number, +/- n users would be the goal) > >>>> Mostly for the 'getting a feel for the system' part of the test, the > >>>> initial setup of it all. > >>>> > >>>> Regards, > >>>> Daniel > >>>> > >>>> On Fri, Jun 15, 2012 at 7:24 AM, Kirk Pepperdine > >>>> <[email protected]> wrote: > >>>> > Hi, > >>>> > > >>>> > I'm very happy to add details if need be. > >>>> > > >>>> > Regards, > >>>> > Kirk > >>>> > > >>>> > On 2012-06-15, at 12:13 AM, Philippe Mouawad wrote: > >>>> > > >>>> >> Bugzilla created: > >>>> >> > >>>> >> - https://issues.apache.org/bugzilla/show_bug.cgi?id=53418 > >>>> >> > >>>> >> > >>>> >> Regards > >>>> >> > >>>> >> Philippe M. > >>>> >> > >>>> >> On Thu, Jun 14, 2012 at 10:30 PM, Philippe Mouawad < > >>>> >> [email protected]> wrote: > >>>> >> > >>>> >>> Hi M. Pepperdine, > >>>> >>> > >>>> >>> On Wed, Jun 13, 2012 at 7:05 AM, Kirk Pepperdine < > >>>> >>> [email protected]> wrote: > >>>> >>> > >>>> >>>> Hi Sebb, > >>>> >>>> > >>>> >>>> We've had this conversation before and I did some preliminary work > >>>> to > >>>> >>>> setup a different type of thread group but the couplings between the > >>>> >>>> existing thread group and the model meant that an extensive > >>>> refactoring > >>>> >>>> would be involved. Since that involves a *lot* more than just a > >>>> simple > >>>> >>>> plugin... > >>>> >>>> > >>>> >>>> So, the current implementation supports a closed system model > >>>> meaning, > >>>> >>>> rate of entry into the system equals rate of exit from the > >>>> system.This is > >>>> >>>> exactly what you want if you're load testing a call centre where > >>>> the number > >>>> >>>> of servers (operators) is fixed and gate entry into the system. > >>>> 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). > >>>> >>> > >>>> >>> What makes you think JMeter does this ? > >>>> >>> > >>>> >>> > >>>> >>>> More over, those that attend my performance tuning seminars come to > >>>> >>>> understand why this is an important aspect of getting your test > >>>> environment > >>>> >>>> right and test harness correctly setup as it can adversely affect > >>>> the > >>>> >>>> quality of your test which can and often does, change the results > >>>> of the > >>>> >>>> test. > >>>> >>>> > >>>> >>> > >>>> >>>> As an example, today I will show a group how to tune an application > >>>> by a > >>>> >>>> partner company. That application has a number of "performance > >>>> problems" > >>>> >>>> backed into it. If I use the traditional means of using JMeter I > >>>> will find > >>>> >>>> a different set of performance issues than if I load with a pattern > >>>> that is > >>>> >>>> similar that found in production. > >>>> >>> > >>>> >>> Can you clarify this point ? a figure might be better than a long > >>>> text > >>>> >>> > >>>> >>> > >>>> >>>> In other words, with this particular application, JMeter exposes > >>>> >>>> "problems" that are artifacts of how it wants to inject load on a > >>>> system. > >>>> >>> > >>>> >>> Not clear for me. > >>>> >>> > >>>> >>> I can fix all of these problems > >>>> >>> > >>>> >>> What are these problems ? and how do you fix these ? > >>>> >>> > >>>> >>> > >>>> >>>> and eventually I'll get to a point where I'll fix everything that > >>>> needs > >>>> >>>> to be fixed. That said, if I can coerce JMeter to load as an open > >>>> system > >>>> >>>> I'll get to the problems without having to fix the artifacts (the > >>>> things > >>>> >>>> that really don't need fixing). > >>>> >>> > >>>> >>> Still not clear > >>>> >>> > >>>> >>>> To coerce JMeter into being an open system requires one to use a > >>>> large > >>>> >>>> number of very short lived threads. So I may only have 400-500 > >>>> active > >>>> >>>> threads at any point in time but in order to achieve that load over > >>>> a 1 or > >>>> >>>> two hour test I may have to specify 10s of thousands of threads. > >>>> Since all > >>>> >>>> of the threads are created up front, this simply doesn't work. > >>>> >>>> > >>>> >>>> You might ask why not just specify 400-500 threads and loop over > >>>> them? in > >>>> >>>> theory you'd think it would work but as you tune the system and the > >>>> >>>> performance characteristics change. Going back to the baked > >>>> application, > >>>> >>>> before I start tuning, the active user count is several thousand. > >>>> In other > >>>> >>>> words, the tuned system is better able to clear users out and that > >>>> changes > >>>> >>>> the performance profile in a way that hard to emulate with the > >>>> current > >>>> >>>> looping behaviour. Using a setting of looping 400 or so threads > >>>> isn't > >>>> >>>> adequate for the initial load tests as the test harness will become > >>>> thread > >>>> >>>> starved and that releases pressure on the server which in turn > >>>> changes the > >>>> >>>> performance profile. > >>>> >>>> > >>>> >>> > >>>> >>> > >>>> >>>> With all due respect to the wonderful work that everyone on the > >>>> project > >>>> >>>> has done, it is my opinion that the one user == one thread is a > >>>> design > >>>> >>>> mistake that has a huge impact on both the usability of the tool > >>>> >>>> > >>>> >>> Examples ? > >>>> >>> > >>>> >>>> and the quality of the results > >>>> >>> > >>>> >>> I disagree with this assertion . We have been using JMeter for load > >>>> >>> testing all kind of applications Intranets / Large ECommerce Systems > >>>> / > >>>> >>> Backoffice systems / , and quality of results is good provided you > >>>> >>> configure it properly. > >>>> >>> Particularly when using Remote Testing. Lot of users in this > >>>> mailing list > >>>> >>> use it and are satisfied (I think). > >>>> >>> > >>>> >>> > >>>> >>>> one can achieve when using it. IMHO, moving to an thread pool/event > >>>> heap > >>>> >>>> based model would be an enormous improvement over the current > >>>> >>>> implementation. > >>>> >>>> > >>>> >>>> Agree it would be better. We will work on it. > >>>> >>> > >>>> >>>> Regards, > >>>> >>>> Kirk > >>>> >>>> > >>>> >>>> On 2012-06-13, at 1:02 AM, sebb wrote: > >>>> >>>> > >>>> >>>>> On 12 June 2012 22:57, Kirk Pepperdine <[email protected]> > >>>> >>>> wrote: > >>>> >>>>>> > >>>> >>>>>> On 2012-06-13, at 12:54 AM, sebb wrote: > >>>> >>>>>> > >>>> >>>>>>> On 12 June 2012 22:06, Kirk Pepperdine < > >>>> [email protected]> > >>>> >>>> wrote: > >>>> >>>>>>>> Hi, > >>>> >>>>>>>> > >>>> >>>>>>>> I figured thread pooling would be revolutionary so I wasn't > >>>> >>>> suggesting that. I would be very useful just delay the creation of > >>>> a thread > >>>> >>>> until it was asked for. > >>>> >>>>>>> > >>>> >>>>>>> Not sure I understand how it would help to delay the thread > >>>> creation, > >>>> >>>>>>> except perhaps for the case where the first threads have finished > >>>> >>>>>>> processing by the time the last threads start running samples. > >>>> >>>>>> > >>>> >>>>>> Bingo!!! ;-) > >>>> >>>>> > >>>> >>>>> So what percentage of use cases need to follow this model? > >>>> >>>>> > >>>> >>>>> Most of the JMeter testing I have done was long running tests where > >>>> >>>>> all threads were active for most of the run. > >>>> >>>>> > >>>> >>>>>> Kirk > >>>> >>>>>> > >>>> >>>>>> > >>>> >>>>>> > >>>> --------------------------------------------------------------------- > >>>> >>>>>> To unsubscribe, e-mail: [email protected] > >>>> >>>>>> For additional commands, e-mail: [email protected] > >>>> >>>>>> > >>>> >>>>> > >>>> >>>>> > >>>> --------------------------------------------------------------------- > >>>> >>>>> To unsubscribe, e-mail: [email protected] > >>>> >>>>> For additional commands, e-mail: [email protected] > >>>> >>>>> > >>>> >>>> > >>>> >>>> > >>>> >>>> > >>>> --------------------------------------------------------------------- > >>>> >>>> To unsubscribe, e-mail: [email protected] > >>>> >>>> For additional commands, e-mail: [email protected] > >>>> >>>> > >>>> >>>> > >>>> >>> > >>>> >>> > >>>> >>> -- > >>>> >>> Cordialement. > >>>> >>> Philippe Mouawad. > >>>> >>> > >>>> >>> > >>>> >>> > >>>> >>> > >>>> >> > >>>> >> > >>>> >> -- > >>>> >> Cordialement. > >>>> >> Philippe Mouawad. > >>>> > > >>>> > > >>>> > --------------------------------------------------------------------- > >>>> > To unsubscribe, e-mail: [email protected] > >>>> > For additional commands, e-mail: [email protected] > >>>> > > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: [email protected] > >>>> For additional commands, e-mail: [email protected] > >>>> > >>>> > >>> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > > > -- > Cordialement. > Philippe Mouawad. > > >
