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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
