database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-28 23:42:10 +03:00
Code Activity

Add the ability to compute per-statement latencies (ie, average execution

Browse Source 
times) to pgbench.

Florian Pflug, reviewed by Greg Smith
This commit is contained in:
Tom Lane
2010-08-12 20:39:39 +00:00
parent 47eeb5e662
commit 5a4e19abe6
2 changed files with 256 additions and 66 deletions
Download Patch File Download Diff File Expand all files Collapse all files

95
doc/src/sgml/pgbench.sgml
View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/pgbench.sgml,v 1.17 2010/07/29 19:34:40 petere Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/pgbench.sgml,v 1.18 2010/08/12 20:39:39 tgl Exp $ -->
<sect1 id="pgbench">
<title>pgbench</title>
@ -38,7 +38,9 @@ tps = 85.296346 (excluding connections establishing)
settings. The next line reports the number of transactions completed
and intended (the latter being just the product of number of clients
and number of transactions per client); these will be equal unless the run
failed before completion. The last two lines report the TPS rate,
failed before completion. (In <literal>-T</> mode, only the actual
number of transactions is printed.)
The last two lines report the TPS rate,
figured with and without counting the time to start database sessions.
</para>
@ -125,6 +127,15 @@ pgbench <optional> <replaceable>options</> </optional> <replaceable>dbname</>
<variablelist>
<varlistentry>
<term><option>-i</option></term>
<listitem>
<para>
Required to invoke initialization mode.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>-F</option> <replaceable>fillfactor</></term>
<listitem>
@ -137,15 +148,6 @@ pgbench <optional> <replaceable>options</> </optional> <replaceable>dbname</>
</listitem>
</varlistentry>
<varlistentry>
<term><option>-i</option></term>
<listitem>
<para>
Required to invoke initialization mode.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>-s</option> <replaceable>scale_factor</></term>
<listitem>
@ -294,6 +296,17 @@ pgbench <optional> <replaceable>options</> </optional> <replaceable>dbname</>
</listitem>
</varlistentry>
<varlistentry>
<term><option>-r</option></term>
<listitem>
<para>
Report the average per-statement latency (execution time from the
perspective of the client) of each command after the benchmark
finishes. See below for details.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>-s</option> <replaceable>scale_factor</></term>
<listitem>
@ -618,7 +631,7 @@ END;
<replaceable>nnn</> is the PID of the pgbench process.
If the <literal>-j</> option is 2 or higher, creating multiple worker
threads, each will have its own log file. The first worker will use the
same name for its log file as in the standard single worker case.
same name for its log file as in the standard single worker case.
The additional log files for the other workers will be named
<filename>pgbench_log.<replaceable>nnn</>.<replaceable>mmm</></filename>,
where <replaceable>mmm</> is a sequential number for each worker starting
@ -632,7 +645,7 @@ END;
<replaceable>client_id</> <replaceable>transaction_no</> <replaceable>time</> <replaceable>file_no</> <replaceable>time_epoch</> <replaceable>time_us</>
</synopsis>
where <replaceable>time</> is the elapsed transaction time in microseconds,
where <replaceable>time</> is the total elapsed transaction time in microseconds,
<replaceable>file_no</> identifies which script file was used
(useful when multiple scripts were specified with <literal>-f</>),
and <replaceable>time_epoch</>/<replaceable>time_us</> are a
@ -653,6 +666,62 @@ END;
</para>
</sect2>
<sect2>
<title>Per-statement latencies</title>
<para>
With the <literal>-r</> option, <application>pgbench</> collects
the elapsed transaction time of each statement executed by every
client. It then reports an average of those values, referred to
as the latency for each statement, after the benchmark has finished.
</para>
<para>
For the default script, the output will look similar to this:
<screen>
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1
query mode: simple
number of clients: 10
number of threads: 1
number of transactions per client: 1000
number of transactions actually processed: 10000/10000
tps = 618.764555 (including connections establishing)
tps = 622.977698 (excluding connections establishing)
statement latencies in milliseconds:
0.004386 \set nbranches 1 * :scale
0.001343 \set ntellers 10 * :scale
0.001212 \set naccounts 100000 * :scale
0.001310 \setrandom aid 1 :naccounts
0.001073 \setrandom bid 1 :nbranches
0.001005 \setrandom tid 1 :ntellers
0.001078 \setrandom delta -5000 5000
0.326152 BEGIN;
0.603376 UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;
0.454643 SELECT abalance FROM pgbench_accounts WHERE aid = :aid;
5.528491 UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid;
7.335435 UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid;
0.371851 INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP);
1.212976 END;
</screen>
</para>
<para>
If multiple script files are specified, the averages are reported
separately for each script file.
</para>
<para>
Note that collecting the additional timing information needed for
per-statement latency computation adds some overhead. This will slow
average execution speed and lower the computed TPS. The amount
of slowdown varies significantly depending on platform and hardware.
Comparing average TPS values with and without latency reporting enabled
is a good way to measure if the timing overhead is significant.
</para>
</sect2>
<sect2>
<title>Good Practices</title>