[Benchmarking] Load generator: number of threads and number of requests

[Andrea Aime]

Hi,
last year we executed each run using the following load profile:
1 thread - 100 requests
10 threads - 200 requests
20 threads - 400 requests
40 threads - 800 requests

One complaint about last year setup was that, having 8 execution
units, the first step was too steep and was hiding how the
servers were scaling up.

So this year we' trying to use powers of two instead.
I'd suggest the following:
1 thread - 100 requests
2 threads - 100 requests
4 threads - 200 requests
8 threads - 200 requests
16 threads - 400 requests
32 threads - 400 requests
64 threads - 800 requests

This would total 2200 requests per run, which we'll generate
using the wms_request.py tool created by Frank so that none
of them is equal to another
(if you're not familiar with it see
  http://svn.osgeo.org/osgeo/foss4g/benchmarking/scripts/ )

How does it look? Too many threads? Not enough?
Too many requests?

Another complain last year was that requests were a bit
too "light", as in they did not contain many features inside
the viewing area (also, due to randomness in the bbox used,
a few requests were completely empty).

I guess this year we'll make sure to generate maps that are
filled enough with data by visual inspection.
In general I think we should try to make sure image encoding
does not end up dominating the overall request time, at
least for vector data.
What do you think?

Cheers
Andrea

-- 
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.