On Tue, Nov 6, 2012 at 1:31 AM, Jeff Janes <jeff.janes@xxxxxxxxx> wrote: > On Mon, Nov 5, 2012 at 2:58 PM, Marko Kreen <markokr@xxxxxxxxx> wrote: >> On Sun, Nov 4, 2012 at 1:53 AM, Jeff Janes <jeff.janes@xxxxxxxxx> wrote: >>> On a 4 CPU machine, if I run pgbench -c10 -j10 with dummy queries >>> (like "select 1;" or "set timezone...") against 2 instances of >>> pgbouncer, I get nearly twice the throughput as if I use only one >>> instance. >>> >>> A rather odd workload, maybe, but it does seem to be similar to the >>> one that started this thread. >> >> Every-connection-is-busy is pessimal workload for pgbouncer, >> as it has nothing useful to contribute to setup, just overhead. > > It still has something to contribute if connections are made and > broken too often (pgbench -C type workload), as seems to be the case > here. I did not notice -C in your message above. In such case, in a practical, non-pgbench workload, you should move pgbouncer to same machine as app, so any overhead is just CPU, spread over all app instances, and does not include network latency. > If he can get an application-side pooler (or perhaps just a change in > configuration) such that the connections are not made and broken so > often, then removing pgbouncer from the loop would probably be a win. Yes, if app has good pooling, there is less use for pgbouncer. In any case, only long connections should go over network. -- marko -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
