Re: pgbench rate limiting changes transaction latency computation

Hello Andres,

> I noticed that pgbench's -R influences not just the computation of lag,
> but also of latency. That doesn't look right to me, but maybe I'm just
> missing something?
>
> It's quite easy to demonstrate when running pgbench with/without
> progress report at a transaction rate that's around the limit of what
> the server can do:
>
> andres(at)alap4:~/src/postgresql$ pgbench -n -M prepared -c 1 -j 1 -T 100000 -P1 -r -S pgbench_10
> progress: 1.0 s, 37416.3 tps, lat 0.027 ms stddev 0.013
> progress: 2.0 s, 37345.1 tps, lat 0.027 ms stddev 0.011
> progress: 3.0 s, 38787.8 tps, lat 0.026 ms stddev 0.009
> ...
>
> andres(at)alap4:~/src/postgresql$ pgbench -n -M prepared -c 1 -j 1 -T 100000 -P1 -r -S -R 37000 pgbench_10
> progress: 1.0 s, 32792.8 tps, lat 81.795 ms stddev 35.552, lag 81.765 ms
> progress: 2.0 s, 37770.6 tps, lat 113.194 ms stddev 4.651, lag 113.168 ms
> progress: 3.0 s, 37006.3 tps, lat 113.905 ms stddev 5.007, lag 113.878 ms

[...]

> Fabien, is this a bug, or am I misunderstanding something?

This behavior under -R is fully voluntary, and the result above just show
that the database cannot really keep up with the load, which is simply the
case, so for me it is okay to show bad figures.

The idea under throttling is to model a client which would want the result
of a query at a certain point in time, say a query for a web page which is
being generated, which is the scheduled time. It is the when the client
knows it wants an answer. If it is not processed immediately, that is bad
for its client perceived latency.

Whether this is due to lag (i.e. the server is loaded and cannot start to
process the answer) or because the server is slow to answer is irrelevant,
the client is waiting, the web page is not generated, the system is slow.
So latency under -R is really "client latency", not only query latency, as
it is documented.

You can offset the lag to get the query latency only, but from a client
perspective the fact is that the system does not keep up with the
scheduled load is the main information, thus this is what is displayed.
The bad figures reflect a bad behavior wrt handling the load. For me it is
what should be wanted under -R. Maybe it could be more clearly documented,
but for me this is the right behavior, and it is I wanted to measure with
throttling.

Under this performance model, the client would give up its requests after
some time, hence the available --latency-limit option.

--
Fabien.