PATCH: remove nclients/nthreads constraint from pgbench

Remove pgbench constraint that the number of clients must be a multiple of
the number of threads, by sharing clients among threads as evenly as
possible.

Rational: allows to test the database load with any number of client
without unrelated constraint. The current setting means for instance that
testing with a prime number of clients always uses one thread, whereas
other number of clients can use a different number of threads. This
constraint does not make much sense.

--
Fabien.

Minor v2 update to change a not badly chosen variable name.

--
Fabien.

On 05/08/2015 03:02 PM, Fabien COELHO wrote:
>
> Remove pgbench constraint that the number of clients must be a multiple of
> the number of threads, by sharing clients among threads as evenly as
> possible.
>
> Rational: allows to test the database load with any number of client
> without unrelated constraint. The current setting means for instance that
> testing with a prime number of clients always uses one thread, whereas
> other number of clients can use a different number of threads. This
> constraint does not make much sense.
> ..
> Minor v2 update to change a not badly chosen variable name.

+1, it's really annoying that you can't just do -j<high number> and
always run with that.

This doesn't behave correctly if you set -j to greater than -c, and also
use the rate limit option:

---- This works ----
$ ./pgbench -R 100 -j3 -c 3 -T 10 postgres
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 5
query mode: simple
number of clients: 3
number of threads: 3
duration: 10 s
number of transactions actually processed: 1031
latency average: 1.397 ms
latency stddev: 0.276 ms
rate limit schedule lag: avg 0.119 (max 1.949) ms
tps = 102.947257 (including connections establishing)
tps = 102.967251 (excluding connections establishing)

---- This does not; too small TPS ----
$ ./pgbench -R 100 -j100 -c 3 -T 10 postgres
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 5
query mode: simple
number of clients: 3
number of threads: 100
duration: 10 s
number of transactions actually processed: 40
latency average: 3.573 ms
latency stddev: 1.724 ms
rate limit schedule lag: avg 0.813 (max 4.722) ms
tps = 3.246618 (including connections establishing)
tps = 3.246639 (excluding connections establishing)

I think that can be fixed by just setting nthreads internally to
nclients, if nthreads > nclients. But please double-check that the logic
used to calculate throttle_delay makes sense in general, when nthreads
is not a multiple of nclients.

- Heikki

> This doesn't behave correctly if you set -j to greater than -c, and also use
> the rate limit option:
> [...]
>
> I think that can be fixed by just setting nthreads internally to nclients, if
> nthreads > nclients. But please double-check that the logic used to calculate
> throttle_delay makes sense in general, when nthreads is not a multiple of
> nclients.

Indeed, I probably did not consider nthreads > nclients. The fix you
suggest seems ok. I'll check it before sending a new v3.

--
Fabien.

> This doesn't behave correctly if you set -j to greater than -c, and also use
> the rate limit option:

Indeed. v3 attached fixed the case when nthreads > nclients.

--
Fabien.

On 07/03/2015 07:50 AM, Fabien COELHO wrote:
>> This doesn't behave correctly if you set -j to greater than -c, and also use
>> the rate limit option:
>
> Indeed. v3 attached fixed the case when nthreads > nclients.

Ok, committed. Thanks!

- Heikki

>> Indeed. v3 attached fixed the case when nthreads > nclients.
>
> Ok, committed. Thanks!

Thanks!

--
Fabien.