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 <seb...@gmail.com> wrote: > On 17 June 2012 13:57, Flavio Cysne <flaviocy...@gmail.com> 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 <flaviocy...@gmail.com> > > > >> Errata: > >> > >> The first "If Controller" is executed and update a property named > >> "currentThreads" ... > >> > >> > >> 2012/6/15 Flavio Cysne <flaviocy...@gmail.com> > >> > >>> 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 <dmwmailingl...@gmail.com> > >>> > >>>> 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 > >>>> <kirk.pepperd...@gmail.com> 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 < > >>>> >> philippe.moua...@gmail.com> wrote: > >>>> >> > >>>> >>> Hi M. Pepperdine, > >>>> >>> > >>>> >>> On Wed, Jun 13, 2012 at 7:05 AM, Kirk Pepperdine < > >>>> >>> kirk.pepperd...@gmail.com> 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 < > kirk.pepperd...@gmail.com> > >>>> >>>> wrote: > >>>> >>>>>> > >>>> >>>>>> On 2012-06-13, at 12:54 AM, sebb wrote: > >>>> >>>>>> > >>>> >>>>>>> On 12 June 2012 22:06, Kirk Pepperdine < > >>>> kirk.pepperd...@gmail.com> > >>>> >>>> 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: user-unsubscr...@jmeter.apache.org > >>>> >>>>>> For additional commands, e-mail: user-h...@jmeter.apache.org > >>>> >>>>>> > >>>> >>>>> > >>>> >>>>> > >>>> --------------------------------------------------------------------- > >>>> >>>>> To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org > >>>> >>>>> For additional commands, e-mail: user-h...@jmeter.apache.org > >>>> >>>>> > >>>> >>>> > >>>> >>>> > >>>> >>>> > >>>> --------------------------------------------------------------------- > >>>> >>>> To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org > >>>> >>>> For additional commands, e-mail: user-h...@jmeter.apache.org > >>>> >>>> > >>>> >>>> > >>>> >>> > >>>> >>> > >>>> >>> -- > >>>> >>> Cordialement. > >>>> >>> Philippe Mouawad. > >>>> >>> > >>>> >>> > >>>> >>> > >>>> >>> > >>>> >> > >>>> >> > >>>> >> -- > >>>> >> Cordialement. > >>>> >> Philippe Mouawad. > >>>> > > >>>> > > >>>> > > --------------------------------------------------------------------- > >>>> > To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org > >>>> > For additional commands, e-mail: user-h...@jmeter.apache.org > >>>> > > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org > >>>> For additional commands, e-mail: user-h...@jmeter.apache.org > >>>> > >>>> > >>> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org > For additional commands, e-mail: user-h...@jmeter.apache.org > > -- Cordialement. Philippe Mouawad.
