1

I'm about to migrate my (tiny) server farm to Google Cloud Platform and so giving the architecture a small restyling. One of the changes I'm about to commit is the introduction of pgBouncer, to manage pooling (ATM I'm having only one DB server with Debian Jessie).

But I cant' find anywhere (or I need improving my Googling skills :-) ) this kind of information:

If I install pgBouncer on the same machine where PostgreSQL runs, will it impact performance? (my primary concerns are about I/O, while CPU and memory can always be improved). Is it better to install it somewhere else?

Thanks in advance

Morenz
  • 23
  • 5

1 Answers1

1

Unless you're on the very extremes of performance requirements (or on woefully underpowered hardware), I wouldn't expect running pgbouncer on the DB server would be noticeable. However, what you might like to consider is the network connection between the DB clients and the server. Specifically, if you put pgbouncer on the client, then it will make the 'over-the-network' connections to the DB server and keep them alive avoiding repeated TCP handshakes, and the client will then be making a really quick local connection to pgbouncer. If you put pgbouncer on the DB server, then there is no advantage network connection-wise (the client has to make a TCP connection to the remote DB server), and all pgbouncer is doing is being a connection pool.

Craig Miskell
  • 4,086
  • 1
  • 15
  • 16
  • The "client" is actually the web server VM directly connected to the database server VM that hosts web services dealing with DB. It creates a connection, does what it has to do, and closes it. Having a connection pooler will surely decrease network usage, but I think I can lower max_connections and so PostgreSQL overall resource usage. Am I wrong? – Morenz Feb 24 '16 at 11:35
  • A connection pooler decreases the overhead (network and otherwise) of making a connection to the database; the client (web code in this case) will still have the overhead of connecting to the connection pooler, which is why I suggested putting the connection pooler closer to the web than the DB. It won't affect the amount of network traffic used by queries. Regardless of where you put your pooler, it does afford the opportunity to configure max_connections to match (slightly exceed?) the number of connections that could come from the pooler though, which can be useful, yes. – Craig Miskell Feb 25 '16 at 18:51