On 31 August 2012 16:12, Shay Ginsbourg <sginsbo...@gmail.com> wrote: > Well done! > > Which JMeter version has all that implemented in? >
The next version - which will likely be 2.8. > > > > > On Fri, Aug 31, 2012 at 3:04 PM, sebb <seb...@gmail.com> 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 <philippe.moua...@gmail.com> 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 <philippe.moua...@gmail.com> >> >> Cc: JMeter Users List <user@jmeter.apache.org> >> >> >> >> >> >> 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 <philippe.moua...@gmail.com> >> >> 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 <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: "th >> >> >> >> >> >> >> >> -- >> >> 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 >> > > > > -- > > 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: sginsbo...@gmail.com > > > 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: 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
