Well done! Which JMeter version has all that implemented in?
On Fri, Aug 31, 2012 at 3:04 PM, sebb <[email protected]> wrote: > > 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] > -- Regards, Shay Ginsbourg Regulatory & Testing Affairs Consultant WWW.GINSBOURG.COM Providing Regulatory, Medical & Performance Testing services since 2008: * IEC 62304 Medical Device Software Life Cycle * IEEE 829 Software Test Documentation * ISO 14971 Medical Device Risk Management * FDA 21 CFR Part 11 Software Validation * IEC 60601-1:2005 3rd ED PEMS - Medical Electrical Equipment * End-to-end verification, validation, and testing (VV&T) * FDA and CE submissions * Open source free testing tools implementation * Functionality and regression testing * Software Performance & Load testing * Software Testing Advanced Automation * Medical Software Verification & Validation * Medical Device Verification & Validation * Medical Device Regulatory Submission * Organizational Regulatory Qualification Formerly QA Manager of LoadRunner at Mercury Interactive M.Sc. cum laude in Bio-Medical Engineering M.Sc. in Mechanical Engineering Work: +972(0)3-5185873 Mobile: +972(0)54-6690915 Email: [email protected] Visit my personal page on LinkedIn at: http://www.linkedin.com/in/shayginsbourg Please consider your environmental responsibility before printing this e-mail. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
