Just to follow up - we have now implemented changes to the TestCompiler and JavaSamplers to reduce the long-term memory storage needed.
The memory requirement imposed by JMeter itself is now proportional to the number of active threads; when a thread completes, its memory should be released. In conjunction with the Thread Group delayed thread creation option and a long ramp-up, it's now possible to run a test with hundreds of thousands of threads (possibly over a million), so long as the number of concurrent (active) threads is kept to a reasonable number. On 7 August 2012 08:54, Philippe Mouawad <[email protected]> wrote: > Hello Kirk, > Thank you very much for your feedback. > Waiting for the big test result. > > Regards > Philippe > > On Monday, August 6, 2012, Philippe Mouawad wrote: > >> From kirk (bad subject due to vacation message :) ) : >> >> >> >> Hi Phillippe, >> >> The on demand thread group worked brilliantly for my short test. I'll repeat >> with an 8 hour >> run to give it an even better test and let you know how that worked. >> >> -- Kirk >> >> >> ---------- Forwarded message ---------- >> From: *Kirk Pepperdine* >> Date: Monday, August 6, 2012 >> Subject: JMeter threading model >> To: Philippe Mouawad <[email protected]> >> Cc: JMeter Users List <[email protected]> >> >> >> 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: "th >> >> >> >> -- >> Cordialement. >> Philippe Mouawad. >> >> >> >> > > -- > Cordialement. > Philippe Mouawad. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
