1

We are currently using Pgbouncer(installed on database server) for database connection pooling. At the same time we use Npgsql Library which has its own connection pool. I have read recommendations that we should disable pooling in Npgsql and use only Pgbouncer.

There is a performance problem when we disable connection pooling in Npgsql. According to my test, it takes 100 ms to connect to pgbouncer. Latency to server with PgBouncer is <1ms.

Executing 5 queries with 5 connections will take more than 500ms, which is too much.

Are we using it correct? That connection latency is killing my performance.

Marcel Kikta
  • 13
  • 5
  • It definitely shouldn't take 100ms to establish a connection to pgbouncer, unless maybe if it doesn't have any idle connections in its pool. Make sure you're closing (i.e. releasing) connections properly, you can follow what's happening in the PostgreSQL logs too. – Shay Rojansky Oct 24 '16 at 17:31
  • Note: I'm assuming pgbouncer is running either on the same machine or very close to your app... – Shay Rojansky Oct 24 '16 at 17:32

2 Answers2

0

I tried to connect to pgbouncer from different server in network and it took from 8 to 22 ms. I am assuming, it is some network issue.

Marcel Kikta
  • 13
  • 5
0

There is no reason to disable connection pooling in Npgsql unless you have errors or compatibility issues.

PGBouncer helps with scalability by handling many more concurrent connections at once without overloading Postgres (which creates a process for each new connection). This does not mean that creating new connections is any faster, so it's better to reuse an existing pool.

Npgsql would maintain a pool of connections from your application to pgbouncer, and pgbouncer would have a pool of connections from itself to Postgres. This works fine and will ensure both network hops are as efficient as possible.

Mani Gandham
  • 7,688
  • 1
  • 51
  • 60