On 11/8/05, sebb <[EMAIL PROTECTED]> wrote:
>
> On 08/11/05, Richard Gaywood <[EMAIL PROTECTED]> wrote:
> > Firstly, I have three ThreadGroups in the whole test plan (each with
> it's
> > own JDBC request and CVS config file)
>
> Why do you need 3 Thread Groups?


3 different types of search being carried out on the system during the load
test, abot 30% type1, 65% type2, 5% type3. I couldn't see any way to do that
except to create three Thread Groups and set the number of threads in each
appropriately.

> Secondly, I've figured out how to log all the response times and whatnot
> to
> > an XML file when doing non-GUI testing, and figured out how to reload
> them
> > into JMeter to show the handy-dandy graphs but when I do that the
> throughput
> > doesn't get calculated properly. Is there anyway to get the measured
> > throughput out of a non-GUI test? That would speed my results collation.
> I'm
> > sure I can do it by crunching the XML file's response times but I don't
> want
> > to if I don't have to!
>
> The Summariser (see jmeter.properties) may help here.


Thanks, I will investigate that.

> Thirdly, I want to run my master test plan four times: once with a small
> > number of threads and once with a large number *before* my server's
> admin
> > jobs run at 4AM, and then the small and large number of threads again
> after
> > 4AM. I did this last night as four instances of the JMeter GUI with four
> > scheduled times, but that's rather tedious (and loading four separate
> GUIs
> > was rather hard on the load test server too). I see I can script the
> number
> > of threads (and presumably) the start times on the command line with a
> -J
> > option, but I still need to control the output file names for the XML
> file
> > to store the results. Can I control that over a -J option too? When I
> tried
> > setting it as a user parameter and setting the Filename in the
> > SimpleDataWriter as, for example, ${output.dir}/results1.xml it didn't
> work.
> > Is that because I can't mix-and-match ${} settings and plain text
> settings
> > in the same dialog box?
>
> No, it's because the Listeners create the file before the test has
> started; variables are not resolved then.


Aha, OK, that makes sense.

However, when running in batch (non-GUI), just use the -l command-line flag.
> You can define the result file contents using jmeter.properties.
>
> If you have some fixed and some variable properties, you can use a
> secondary property file (-q flag, I think).


I got around this by using -J on the command line and ${__P(foo)} in the
SimpleDataWriter filename field, but thanks for the suggestion, I'll keep
that in mind in the future.

> Fourthly, I can't find an option to log the number of bytes received in
> the
> > response; this would be a good sanity check for me that the data coming
> back
> > from the server isn't broken (as I'm doing JDBC and therefore don't have
> a
> > HTTP status code). Did I miss one or has this not been implemeted yet?
>
> Not yet implemented.


OK, if I were to write something like that, would you be interested in the
contribution back into the codebase? I'd have to run it by my employer first
though. Also, do you currently offer response size logging for any other
Sampler type? I guess not, but that would (presumably) cut down on the work
I would have to do.
Thanks for your time in writing this response.

Reply via email to