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: tgl(at)sss(dot)pgh(dot)pa(dot)us, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Doubt in pgbench TPS number
Date: 2015-09-29 05:02:11
Message-ID: alpine.DEB.2.10.1509290628160.4859@sto
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


>> (Note: I've not read the patch, so this is not an opinion about its
>> correctness.)
>
> As Fabien anayzed the problem was that pgbench simply uses wrong
> variable: nthreads (number of threads, specified by "-j" option)
> vs. nclients (number of clients, specified by "-c" option).
>
> @@ -2616,7 +2616,7 @@ printResults(int ttype, int64 normal_xacts, int nclients,
> time_include = INSTR_TIME_GET_DOUBLE(total_time);
> tps_include = normal_xacts / time_include;
> tps_exclude = normal_xacts / (time_include -
> - (INSTR_TIME_GET_DOUBLE(conn_total_time) / nthreads));
> + (INSTR_TIME_GET_DOUBLE(conn_total_time) / nclients));
>
> Here conn_total_time is the sum of time to establish connection to
> PostgreSQL. Since establishing connections to PostgreSQL is done in
> serial rather than in parallel, conn_total_time should have been
> divided by nclients.

After some more thinking and looking again at the connection code, I
revise slightly my diagnostic:

- the amount of parallelism is "nclients", as discussed above, when
reconnecting on each transaction (-C) because the connections are managed
in parallel from doCustom,

* BUT *

- if there is no reconnections (not -C) the connections are performed in
threadRun in a sequential way, all clients wait for the connections of
other clients in the same thread before starting processing transactions,
so "nthreads" is the right amount of parallelism in this case.

So on second thought the formula should rather be:

... / (is_connect? nclients: nthreads)

Here is a v2 with this formula. Note that it does not take into account
thread creation time, which might be significant, the start and end of a
pgbench run are quite fuzzy.

I've removed the doCustom parameter change as it is included in a larger
patch I submitted about reworking stat collections in pgbench, so this
attached patch is bug fix only.

For the record, I still plainly disagree with the idea of shipping a
performance measuring tool which knowingly displays wrong and optimistic
figures under some conditions.

--
Fabien.

Attachment Content-Type Size
pgbench-connect-2.patch text/x-diff 1002 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Charles Clavadetscher 2015-09-29 05:50:27 Re: unclear about row-level security USING vs. CHECK
Previous Message Kouhei Kaigai 2015-09-29 04:55:28 Re: Foreign join pushdown vs EvalPlanQual