On Tue, Oct 30, 2012 at 4:58 PM, Jeff Janes <jeff.janes@xxxxxxxxx> wrote: > On Mon, Oct 29, 2012 at 5:11 PM, Catalin Iacob <iacobcatalin@xxxxxxxxx> wrote: > >> pgbouncer 1.4.2 installed from Ubuntu's packages on the same machine >> as Postgres. Django connects via TCP/IP to pgbouncer (it does one >> connection and one transaction per request) and pgbouncer keeps >> connections open to Postgres via Unix socket. > > Isn't pgbouncer single-threaded? > > If you hitting it with tiny queries as fast as possible from 20 > connections, I would think that it would become the bottleneck. Single threaded asynchronous servers are known to scale better for this type of workload than multi-threaded systems because you don't have to do locking and context switching. By 'for this type of workload', I mean workloads where most of the real work done is i/o -- pgbouncer as it's just routing data between network sockets is basically a textbook case for single threaded server. stunnel, by comparison, which has non-triival amounts of non i/o work going on, is more suited for threads. It also has severe scaling limits relative to pgbouncer. pgbouncer is an absolute marvel and should be standard kit in any case you're concerned about server scaling in terms of number of active connections to the database. I'm in the camp that application side connection pools are junk and should be avoided when possible. merlin -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
