Re: pgbench rate limiting changes transaction latency computation

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: pgbench rate limiting changes transaction latency computation
Date: 2019-06-11 06:36:55
Message-ID: alpine.DEB.2.21.1906110819270.31130@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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

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


In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2019-06-11 06:49:03 Re: pg_basebackup failure after setting default_table_access_method option
Previous Message 2019-06-11 06:35:36 RE: [PATCH] memory leak in ecpglib