Re: pgbench rate limiting changes transaction latency computation

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: pgbench rate limiting changes transaction latency computation
Дата
Msg-id 20190611050959.yitlkuzidkv2gx4q@alap3.anarazel.de
обсуждение исходный текст
Ответ на pgbench rate limiting changes transaction latency computation  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
Hi

On 2019-06-10 21:56:31 -0700, Andres Freund wrote:
> 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?

I apparently did:

> -P sec
> --progress=sec
> 
>     Show progress report every sec seconds. The report includes the time
>     since the beginning of the run, the TPS since the last report, and
>     the transaction latency average and standard deviation since the
>     last report. Under throttling (-R), the latency is computed with
>     respect to the transaction scheduled start time, not the actual
>     transaction beginning time, thus it also includes the average
>     schedule lag time.

But that makes very little sense to me. I see that was changed by Heikki
in

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=02e3bcc661598275a75a8649b48602dca7aeec79
>  Change the way latency is calculated with pgbench --rate option.
> 
> The reported latency values now include the "schedule lag" time, that is,
> the time between the transaction's scheduled start time and the time it
> actually started. This relates better to a model where requests arrive at a
> certain rate, and we are interested in the response time to the end user or
> application, rather than the response time of the database itself.
> 
> Also, when --rate is used, include the schedule lag time in the log output.
> 
> The --rate option is new in 9.4, so backpatch to 9.4. It seems better to
> make this change in 9.4, while we're still in the beta period, than ship a
> 9.4 version that calculates the values differently than 9.5.

I find that pretty unconvincing. Report a new field, sure. But what's
the point of changing an *established* field, just due to rate limiting?
At the very least that ought to commented upon in the code as well.

Doesn't this mean that latency and lag are quite redundant, just more
obscure, due this change?

        latency = INSTR_TIME_GET_MICROSEC(*now) - st->txn_scheduled;
        lag = INSTR_TIME_GET_MICROSEC(st->txn_begin) - st->txn_scheduled;

I guess I can just subtract latency from lag to get to the non-throttled
latency. But that is, uh, odd.

Greetings,

Andres Freund



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: pgbench rate limiting changes transaction latency computation
Следующее
От: Andres Freund
Дата:
Сообщение: Re: pg_basebackup failure after setting default_table_access_methodoption