On 08/27/2014 04:08 AM, Heikki Linnakangas wrote:
That model might make some sense if you think e.g. of a web application,
where the web server has a timeout for how long it waits to get a
database connection from a pool, but once a query is started, the
transaction is considered a succeess no matter how long it takes. The
latency limit would be that timeout. But I think a more useful model is
that when the user clicks a button, he waits at most X seconds for the
result. If that deadline is exceeded, the web server will give a 404, or
the user will simply get bored and go away, and the transaction is
considered a failure.
Correct, the whole TPC-B model better fits an application where client
requests enter a queue at the specified TPS rate and that queue is
processed.
While we are at it,
Note that in the original TPC-B specification the transaction duration
measured is the time from receiving the client request (in current
pgbench under throttling that is for when the transaction is scheduled)
and when the request is answered. This is the client visible response
time, which has nothing to do with the database latency.
As per TPC-B, the entire test is only valid if 90% of all client
response times are within 2 seconds.
It would be useful if pgbench would
A) measure and report that client response time in the per transaction
log files and
B) report at the end what percentage of transactions finished within
a specified response time constraint (default 2 seconds).
Regards,
Jan
--
Jan Wieck
Senior Software Engineer
http://slony.info
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
