Re: How to keep queries low latency as concurrency increases

On Tue, Oct 30, 2012 at 4:58 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
> On Mon, Oct 29, 2012 at 5:11 PM, Catalin Iacob <iacobcatalin(at)gmail(dot)com> 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