On 02/11/2013 07:27 AM, Jeff Janes wrote:
> I created doBenchMarkConnect() to segregate bench-marking connections from
> utility connections. At first I thought of adding the startup code to only
> the normal path and leaving support for -C in the wind, but decided that
> was just lazy.
That sounds very useful and would've eased some recent pgbench work I've
been doing too.
I've put some patches together to make pgbench capable of talking to
multiple servers. I needed it for benchmarking work on bidirectional
replication, but it's also useful if you want to benchmark a group of
hot standbys in read-only mode, and it may be useful with various 3rd
pty replication solutions. As written it uses one or more threads per
server, with all clients managed by a given thread using the same
server. Multiple servers are specified by using connstring style syntax, eg:
pgbench -T 600 -j 4 -c 64 "host=server1 user=postgres"
"host=server2 user=postgres port=5433"
It isn't ready for a commitfest yet as I need to tidy up a few things
and I still haven't added an extra set of timings to measure how long
the DB takes to return to a steady state after the pgbench run, but once
that's done I'll send it in. The after-run timings are intended for
things like measuring how much lag an asynchronous replica has built up
and how long it takes to catch up after the write flood stops, or how
long a CHECKPOINT takes after the pgbench run.
I also have a patch that adds a flag to force a CHECKPOINT after vacuum
and before running its tests. This makes pgbench results _vastly_ more
stable over short runs.
The work is currently lurking in the 'multibench' branch of
git://github.com/ringerc/postgres.git ; see
https://github.com/ringerc/postgres/tree/multibench. Only pgbench.c is
actually changed. Comments appreciated.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
