Dave Cramer www.postgres.rocks
On Tue, 16 May 2023 at 07:27, Andres Freund <and...@anarazel.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
