Re: pgbench: option delaying queries till connections establishment?

Dave Cramer
www.postgres.rocks

On Tue, 16 May 2023 at 07:27, Andres Freund <andres(at)anarazel(dot)de> wrote:

> Hi,
>
> I am trying to run a few benchmarks measuring the effects of patch to
> make GetSnapshotData() faster in the face of larger numbers of
> established connections.
>
> Before the patch connection establishment often is very slow due to
> contention. The first few connections are fast, but after that it takes
> increasingly long. The first few connections constantly hold
> ProcArrayLock in shared mode, which then makes it hard for new
> connections to acquire it exclusively (I'm addressing that to a
> significant degree in the patch FWIW).
>
> But for a fair comparison of the runtime effects I'd like to only
> compare the throughput for when connections are actually usable,
> otherwise I end up benchmarking few vs many connections, which is not
> useful. And because I'd like to run the numbers for a lot of different
> numbers of connections etc, I can't just make each run several hour
> longs to make the initial minutes not matter much.
>
> Therefore I'd like to make pgbench wait till it has established all
> connections, before they run queries.
>
> Does anybody else see this as being useful?
>
> If so, should this be done unconditionally? A new option? Included in an
> existing one somehow?
>
> Greetings,

Andres Freund
>

I've recently run into something I am having difficulty understanding.

I am running pgbench with the following
pgbench -h localhost -c 100 -j 100 -t 2 -S -s 1000 pgbench -U pgbench
--protocol=simple

Without pgbouncer I get around 5k TPS
with pgbouncer I get around 15k TPS

Looking at the code connection initiation time should not be part of the
calculation so I' puzzled why pgbouncer is making such a dramatic
difference ?

Dave