Hi Kirk,
just a thought on this case, and if you start as many JMeter instances
(using servers or not) as needed, once at a time, to increase the load,
let's say, pseudo-dynamically?
I think this way you could, in some way, achieve the desired load. The
"hard work" will be on merging jtl files in only one big jtl file to
generate reports.
I have to agree with you that increasing/decreasing dynamically the
load is better than starting many tests to pin-point a spot on the graph.
Hope it helps you.
Flávio Cysne
2012/6/13 Kirk Pepperdine <kirk.pepperd...@gmail.com>
> 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). 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. In other words, with this particular
> application, JMeter exposes "problems" that are artifacts of how it wants
> to inject load on a system. I can fix all of these problems 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). 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 and the
> quality of the results 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.
>
> Regards,
> Kirk
>
> On 2012-06-13, at 1:02 AM, sebb wrote:
>
> > On 12 June 2012 22:57, Kirk Pepperdine <kirk.pepperd...@gmail.com>
> wrote:
> >>
> >> On 2012-06-13, at 12:54 AM, sebb wrote:
> >>
> >>> On 12 June 2012 22:06, Kirk Pepperdine <kirk.pepperd...@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-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
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org
> For additional commands, e-mail: user-h...@jmeter.apache.org
>
>
