Hello Tom,
> # progress: 2.6 s, 6.9 tps, lat 0.000 ms stddev 0.000, lag 0.000 ms, 18 skipped
> # progress: 3.0 s, 0.0 tps, lat -nan ms stddev -nan, lag -nan ms, 0 skipped
> # progress: 4.0 s, 1.0 tps, lat 2682.730 ms stddev 0.000, lag 985.509 ms, 0 skipped
> (BTW, the "-nan" bits suggest an actual pgbench bug, independently of
> anything else.)
From my point of view, NaN is expected when no test were executed in the
interval: if there was no transaction, it does not make sense to talk
about its latency, so NaN is the right answer.
However, the above "6.9 tps, lat 0.000, stddev 0.000, lag 0.000" is
inconsistent. As "6.9 = 18 / 2.6", it means that progress tps calculation
should remove skipped transactions...
Attached patch attempts to report more consistent figures in the progress
and in final report when transactions are skipped.
sh> cat sleep-100.sql
\sleep 100 ms
SELECT 1;
sh> ./pgbench -P 1 -t 100 -f sleep-100.sql -R 20 -L 1
[...]
progress: 1.0 s, 7.0 tps, lat 100.145 ms stddev 0.042, lag 0.000 ms, 16 skipped
progress: 2.0 s, 6.0 tps, lat 100.133 ms stddev 0.040, lag 0.021 ms, 7 skipped
progress: 3.0 s, 9.0 tps, lat 100.115 ms stddev 0.016, lag 0.000 ms, 11 skipped
[...]
number of transactions actually processed: 38/100
number of transactions skipped: 62 (62.000 %)
number of transactions above the 1.0 ms latency limit: 38 (38.000 %)
latency average = 100.142 ms
tps = 7.091010 (including connections establishing)
tps = 7.094144 (excluding connections establishing)
script statistics:
- number of transactions skipped: 62 (62.000%)
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers