On 24/02/2010, Brett Cave <[email protected]> wrote:
> On Wed, Feb 24, 2010 at 4:28 AM, sebb <[email protected]> wrote:
>
> > On 19/02/2010, Brett Cave <[email protected]> wrote:
> > >
>
> > > Is there a way to combine all the threadGroups into a single test plan
> > and
> > > have each threadgroup log results to a different file so we can draw the
> > > reports we need from different files?
> >
> > Yes, just add a Simple Data Writer to each thread group; use different
> > file names.
> >
>
>
> Ah, ok - I have been excluding any listeners from the test plan and starting
> up with the -l parameter. This makes sense. I have also started writing a
> MySQLListener for JMeter that will log to db rather than file, this will
> make reporting substantially easier (post to follow soon on how to do this).
>
>
>
> >
> > > What would be the most effective (from
> > > managing the test plans perspective) way to structure this?
> >
> > I'm not entirely clear how the test plans differ.
> > If they are sufficiently similar that they can be parameterised, then
> > the same plan can be used for different purposes. E.g. thread count
> > and ramp-up could be defined using the __P() function, and the values
> > passed in on the command-line, e.g.
> >
> > jmeter -n -t testplan.jmx -Jthreads=20 -ltestplan20.jtl -jtestplan20.log
> >
>
>
> This is exactly what I am doing (using -G for global / distributed testing
> instead of J), the biggest issue was the reporting. I am calling JMeter from
> a bash script that runs as per cron schedule, so need to automate it as much
> as possible. The test plan is exactly the same for each test, so I would
> like to have 1 siteNav test (instead of 2 of the same tests with different
> thread group configuration). I was using -Gsoak.duration -Gsoak.threads
> -Gstress.period -Gstress.threads as parameters for the 2 different modes, as
> the scheduler is configured differently for each mode.
>
> Thread group configuration similar to:
> Stress test:
> Threads: ${__P(stress.threads,500)}
> Ramp-up: ${__P(stress.period,3600)}
> Loop count: 1
>
> Scheduler: disabled
> # This consistently increases number of threads to stress.threads over
> stress.period seconds.
>
> Soak test:
> Threads: ${__P(soak.threads,100)}
> Ramp-up: 0
> Loop: forever
> Scheduler: Enabled
> Start / End time: a range from far in the past to far in the future, i.e.
> including any time the test may run.
> Duration: ${__P(soak.duration,3600)}
> # This kicks off at soak.threads number of threads immediately, and
> maintains at this level for soak.duration seconds.
>
> As you can see, the thread configuration is quite different, so I would like
> to thread groups with these configurations pointing to the same sampler set
> / test plan (don't think I can get this right with just variations on
> parameters, have checked the XML of the test plans and structure is
> different).
>
> Will I have to use 2 different test plans, 1 for stress and 1 for soak, for
> each test I have ?
If the only difference is in the ThreadGroup settings, it should be
possible to use properties to control them all.
Try something like:
Threads: ${__P(threads)}
Ramp-up: ${__P(ramp_up)}
Loop count: ${__P(loops)}
StartDelay: ${__P(start_delay,0)}
Duration:${__P(duration,99999)}
You can add defaults for either of the run types.
Setting loops = -1 means forever.
If you don't want to stress the server, you can experiment using the
Java Request sampler.
>
> > etc.
> >
> >
> > > thanks.
> > >
> > > brett
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
