On Tue, Dec 22, 2015 at 9:28 PM, Tatsuo Ishii <is...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers