You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jmeter.apache.org by Kirk Pepperdine <ki...@gmail.com> on 2012/08/06 12:40:11 UTC
Re: JMeter threading model
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 <ph...@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 <se...@gmail.com> wrote:
> On 17 June 2012 13:57, Flavio Cysne <fl...@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 <fl...@gmail.com>
> >
> >> Errata:
> >>
> >> The first "If Controller" is executed and update a property named
> >> "currentThreads" ...
> >>
> >>
> >> 2012/6/15 Flavio Cysne <fl...@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 <dm...@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
> >>>> <ki...@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.mouawad@gmail.com> wrote:
> >>>> >>
> >>>> >>> Hi M. Pepperdine,
> >>>> >>>
> >>>> >>> On Wed, Jun 13, 2012 at 7:05 AM, Kirk Pepperdine <
> >>>> >>> kirk.pepperdine@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 <ki...@gmail.com>
> >>>> >>>> wrote:
> >>>> >>>>>>
> >>>> >>>>>> On 2012-06-13, at 12:54 AM, sebb wrote:
> >>>> >>>>>>
> >>>> >>>>>>> On 12 June 2012 22:06, Kirk Pepperdine <
> >>>> kirk.pepperdine@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-unsubscribe@jmeter.apache.org
> >>>> >>>>>> For additional commands, e-mail: user-help@jmeter.apache.org
> >>>> >>>>>>
> >>>> >>>>>
> >>>> >>>>>
> >>>> ---------------------------------------------------------------------
> >>>> >>>>> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
> >>>> >>>>> For additional commands, e-mail: user-help@jmeter.apache.org
> >>>> >>>>>
> >>>> >>>>
> >>>> >>>>
> >>>> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> >>>> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
> >>>> >>>> For additional commands, e-mail: user-help@jmeter.apache.org
> >>>> >>>>
> >>>> >>>>
> >>>> >>>
> >>>> >>>
> >>>> >>> --
> >>>> >>> Cordialement.
> >>>> >>> Philippe Mouawad.
> >>>> >>>
> >>>> >>>
> >>>> >>>
> >>>> >>>
> >>>> >>
> >>>> >>
> >>>> >> --
> >>>> >> Cordialement.
> >>>> >> Philippe Mouawad.
> >>>> >
> >>>> >
> >>>> > ---------------------------------------------------------------------
> >>>> > To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
> >>>> > For additional commands, e-mail: user-help@jmeter.apache.org
> >>>> >
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
> >>>> For additional commands, e-mail: user-help@jmeter.apache.org
> >>>>
> >>>>
> >>>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
> For additional commands, e-mail: user-help@jmeter.apache.org
>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>
>
>
Re: JMeter threading model
Posted by Shay Ginsbourg <sg...@gmail.com>.
Looking forward!
Thanks!
www.ginsbourg.com | 054-6690915 | Sent from my BlackBerry® smartphone from orange.
-----Original Message-----
From: sebb <se...@gmail.com>
Date: Fri, 31 Aug 2012 16:52:48
To: JMeter Users List<us...@jmeter.apache.org>
Reply-To: "JMeter Users List" <us...@jmeter.apache.org>
Subject: Re: JMeter threading model
On 31 August 2012 16:12, Shay Ginsbourg <sg...@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 <se...@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 <ph...@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 <ph...@gmail.com>
>> >> Cc: JMeter Users List <us...@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 <ph...@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 <se...@gmail.com> wrote:
>> >>
>> >> On 17 June 2012 13:57, Flavio Cysne <fl...@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 <fl...@gmail.com>
>> >> >
>> >> >> Errata:
>> >> >>
>> >> >> The first "If Controller" is executed and update a property named
>> >> >> "currentThreads" ...
>> >> >>
>> >> >>
>> >> >> 2012/6/15 Flavio Cysne <fl...@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-unsubscribe@jmeter.apache.org
>> For additional commands, e-mail: user-help@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: sginsbourg@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-unsubscribe@jmeter.apache.org
> For additional commands, e-mail: user-help@jmeter.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
For additional commands, e-mail: user-help@jmeter.apache.org
Re: JMeter threading model
Posted by sebb <se...@gmail.com>.
On 31 August 2012 16:12, Shay Ginsbourg <sg...@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 <se...@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 <ph...@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 <ph...@gmail.com>
>> >> Cc: JMeter Users List <us...@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 <ph...@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 <se...@gmail.com> wrote:
>> >>
>> >> On 17 June 2012 13:57, Flavio Cysne <fl...@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 <fl...@gmail.com>
>> >> >
>> >> >> Errata:
>> >> >>
>> >> >> The first "If Controller" is executed and update a property named
>> >> >> "currentThreads" ...
>> >> >>
>> >> >>
>> >> >> 2012/6/15 Flavio Cysne <fl...@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-unsubscribe@jmeter.apache.org
>> For additional commands, e-mail: user-help@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: sginsbourg@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-unsubscribe@jmeter.apache.org
> For additional commands, e-mail: user-help@jmeter.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
For additional commands, e-mail: user-help@jmeter.apache.org
Re: JMeter threading model
Posted by Shay Ginsbourg <sg...@gmail.com>.
Well done!
Which JMeter version has all that implemented in?
On Fri, Aug 31, 2012 at 3:04 PM, sebb <se...@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 <ph...@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 <ph...@gmail.com>
> >> Cc: JMeter Users List <us...@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 <ph...@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 <se...@gmail.com> wrote:
> >>
> >> On 17 June 2012 13:57, Flavio Cysne <fl...@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 <fl...@gmail.com>
> >> >
> >> >> Errata:
> >> >>
> >> >> The first "If Controller" is executed and update a property named
> >> >> "currentThreads" ...
> >> >>
> >> >>
> >> >> 2012/6/15 Flavio Cysne <fl...@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-unsubscribe@jmeter.apache.org
> For additional commands, e-mail: user-help@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: sginsbourg@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-unsubscribe@jmeter.apache.org
For additional commands, e-mail: user-help@jmeter.apache.org
Re: JMeter threading model
Posted by sebb <se...@gmail.com>.
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 <ph...@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 <ph...@gmail.com>
>> Cc: JMeter Users List <us...@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 <ph...@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 <se...@gmail.com> wrote:
>>
>> On 17 June 2012 13:57, Flavio Cysne <fl...@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 <fl...@gmail.com>
>> >
>> >> Errata:
>> >>
>> >> The first "If Controller" is executed and update a property named
>> >> "currentThreads" ...
>> >>
>> >>
>> >> 2012/6/15 Flavio Cysne <fl...@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-unsubscribe@jmeter.apache.org
For additional commands, e-mail: user-help@jmeter.apache.org
Re: JMeter threading model
Posted by Philippe Mouawad <ph...@gmail.com>.
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 <ph...@gmail.com>
> Cc: JMeter Users List <us...@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 <ph...@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 <se...@gmail.com> wrote:
>
> On 17 June 2012 13:57, Flavio Cysne <fl...@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 <fl...@gmail.com>
> >
> >> Errata:
> >>
> >> The first "If Controller" is executed and update a property named
> >> "currentThreads" ...
> >>
> >>
> >> 2012/6/15 Flavio Cysne <fl...@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.
Fwd: JMeter threading model
Posted by Philippe Mouawad <ph...@gmail.com>.
>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 <ph...@gmail.com>
Cc: JMeter Users List <us...@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 <ph...@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 <se...@gmail.com> wrote:
On 17 June 2012 13:57, Flavio Cysne <fl...@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 <fl...@gmail.com>
>
>> Errata:
>>
>> The first "If Controller" is executed and update a property named
>> "currentThreads" ...
>>
>>
>> 2012/6/15 Flavio Cysne <fl...@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 numbe
--
Cordialement.
Philippe Mouawad.