Re: pgbench rate limiting changes transaction latency computation - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: pgbench rate limiting changes transaction latency computation
Date
Msg-id alpine.DEB.2.21.1906110819270.31130@lancre
Whole thread Raw
In response to pgbench rate limiting changes transaction latency computation  (Andres Freund <andres@anarazel.de>)
Responses Re: pgbench rate limiting changes transaction latency computation
List 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@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@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.



pgsql-hackers by date:

Previous
From: "kuroda.hayato@fujitsu.com"
Date:
Subject: RE: [PATCH] memory leak in ecpglib
Next
From: Andres Freund
Date:
Subject: Re: pg_basebackup failure after setting default_table_access_methodoption