Re: Doubt in pgbench TPS number

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Tatsuo Ishii <ishii(at)postgresql(dot)org>
Cc: PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Doubt in pgbench TPS number
Date: 2015-09-25 05:28:09
Message-ID: alpine.DEB.2.10.1509250712330.21900@sto
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Hello Tatsuo-san,

> $ pgbench -C -n -p 11002 -c 10 -T 30 -f test.sql test
> tps = 95.799114 (including connections establishing)
> tps = 124.487149 (excluding connections establishing)
>
> Interesting thing is, the number from "excluding connections
> establishing". 124.487149 tps means 0.008032 seconds per
> transaction. Since the query executes pg_sleep(0.1), I think the
> number should be equal to or greater than 0.1. Maybe a tolerance, but
> 20% of error seems to be too high for me.

Indeed.

> Note that if "-C" does not present, the TPS number seems to be sane.

Hmmm... I never use -C. The formula seems ok:

tps_exclude = normal_xacts / (time_include -
(INSTR_TIME_GET_DOUBLE(conn_total_time) / nthreads));

conn_total_time is the cumulated time spent by all threads.

A quick look at the logic reveals some minor issues (conn_time is passed
as an argument to doCustom, although it is already available as a "thread"
field, stange). I spotted "threads" used instead of "thread" in an
accumulation, but it is not related to this computation.

Hmmm. I'll have a slower look...

--
Fabien.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amir Rohan 2015-09-25 06:11:33 Re: In-core regression tests for replication, cascading, archiving, PITR, etc.
Previous Message Jeevan Chalke 2015-09-25 05:27:16 Re: TEXT vs VARCHAR join qual push down diffrence, bug or expected?