On Tue, Dec 22, 2015 at 9:28 PM, Tatsuo Ishii <ishii@postgresql.org> wrote:
> While playing with 9.5's pgbench, I faced with a strange behavior.
>
> $ pgbench -p 11002 --rate 2 --latency-limit 1 -c 10 -T 10 test
> starting vacuum...end.
> transaction type: TPC-B (sort of)
> scaling factor: 1
> query mode: simple
> number of clients: 10
> number of threads: 1
> duration: 10 s
> number of transactions actually processed: 16
> number of transactions skipped: 0 (0.000 %)
> number of transactions above the 1.0 ms latency limit: 16 (100.000 %)
> latency average: 5.518 ms
> latency stddev: 1.834 ms
> rate limit schedule lag: avg 0.694 (max 1.823) ms
> tps = 1.599917 (including connections establishing)
> tps = 1.600319 (excluding connections establishing)
>
> From the pgbench manual:
>
> <term><option>--latency-limit=</option><replaceable>limit</></term>
> <listitem>
> <para>
> Transaction which last more than <replaceable>limit</> milliseconds
> are counted and reported separately, as <firstterm>late</>.
> </para>
> <para>
> When throttling is used (<option>--rate=...</>), transactions that
> lag behind schedule by more than <replaceable>limit</> ms, and thus
> have no hope of meeting the latency limit, are not sent to the server
> at all. They are counted and reported separately as
> <firstterm>skipped</>.
>
> 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.
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.
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.)
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.
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company