jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <philippe.moua...@gmail.com>
Subject Re: JMeter threading model
Date Sat, 14 Jul 2012 13:36:07 GMT
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 <sebbaz@gmail.com> wrote:

> On 17 June 2012 13:57, Flavio Cysne <flaviocysne@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 <flaviocysne@gmail.com>
> >
> >> Errata:
> >>
> >> The first "If Controller" is executed and update a property named
> >> "currentThreads" ...
> >>
> >>
> >> 2012/6/15 Flavio Cysne <flaviocysne@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 <dmwmailinglist@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.pepperdine@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 <
> kirk.pepperdine@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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message