Re: pgbench --latency-limit option

Hello Robert & Tatsuo,

Some paraphrasing and additional comments.

>> $ pgbench -p 11002 --rate 2 --latency-limit 1 -c 10 -T 10 test

You are targetting 2 tps over 10 connections, so that is about one
transaction every 5 seconds for each connection, the target is about 20
transactions in 10 seconds. You want transaction latency below 1 *ms*.

>> number of transactions actually processed: 16

The stochastic process scheduled 16 transactions during the 10 seconds,
1.6 tps. In the long run it should be close to 2 tps, if the stochastic
process does its job as expected.

>> number of transactions skipped: 0 (0.000 %)

All transactions were started (i.e. no transaction was skipped).

>> number of transactions above the 1.0 ms latency limit: 16 (100.000 %)

But none responded within 1 ms, they were all late.

>> latency average: 5.518 ms
>> latency stddev: 1.834 ms

Indeed, unlikely to be under 1 ms.

>> In my understanding, this says: any transaction takes longer than the
>> duration specified by --latency-limit (in this case 1.0 ms) will not
>> be sent the sever.

We cannot know that a transaction will take longer before running it.

> I don't think that's what it says. There seem to be three points here:
>
> 1. If the transaction is sent to the server, we'll check whether it
> runs for longer than the amount of time specified by the limit; if so,
> it will be reported separately. This is true with or without --rate.

Yes.

> 2. If --rate is used, we'll calculate the latency for each statement
> based on the time it was due to be sent, rather than the time it
> actually got sent. (This is further clarified in the documentation
> for --rate.)

Yes. The idea is that the client wanted (say a web server) to send a
transaction a time t, but due to the load or whatever it may not have been
able to send it at that time, but it sends it later.

> 3. If --rate is used and the server is so far behind that
> --latency-limit cannot possibly be met, then we'll skip sending the
> query at all.

Yes. The time when the client finally get to send the transaction, the
current time is beyond schedule + delay limit, no way to get an answer
in time, this simulates a client timeout, where the client gives up
getting an answer.

> In your example, you've got 10 connections and are trying to run at 2
> tps, so to avoid having to start skipping things you need transaction
> response times to be <~ 5 ms. The actual response time is ~5.5ms, so
> if you ran the test for longer I think you would see some skips.

Probably no skips though, because the response time needed is below 5
*seconds*, not ms : 2 tps on 10 connections, 1 transaction every 5 seconds
for each connection.

--
Fabien.