5 ms·

at work we run pgbouncer on 4 vCPU (GCP c2-standard-4) machines, at 60% load, and they do ~15k TPS at peak, however we only peak at ~45k connections per node.

by jhgg 4y ago

at work we run pgbouncer on 4 vCPU (GCP c2-standard-4) machines, at 60% load, and they do ~15k TPS at peak, however we only peak at ~45k connections per node. however, i think that you may have a lot left on the table in terms of optimizations that can be made. these numbers seem far under the performance of what i know beam to be capable.

chasers 4y ago
Nice! Yeah really our first go at it so I’m sure we have room to improve. PgBouncer was on the same instance I’m assuming?
- jhgg 4y ago
  nah we run a pool of common pgbouncers that route to the various postgres instances we run. they also run google's cloud sql proxy as well. it's actually haproxy -> pgbouncer -> cloud sql proxy -> postgres. everything but postgres runs on one machine. we use haproxy to load balance replica connections across different pgbouncer backends for replicas of the same db.
  - chasers 4y ago
    Ha! Wait but why Google Cloud SQL proxy too? If you are interested in connecting over this it would be great to connect… chase@supabase.com. We want to do load balancing too. Makes so much sense to do load balancing in the proxy.
    - jhgg 4y ago
      cloud sql proxy makes connecting to cloud managed postgres instances pretty simple/easy. honestly, we dont have a "great" reason other than, we set it up a long time ago, and it's continued to work haha. so pgbouncer connects to cloud sql proxy, which does the connection pooling concern.
egorr 4y ago
Hey, from what we’ve seen up to 50k per node should be ok for supavisor on 4 cores as well. And TPS is here mainly to demonstrate that we not only create dummy connections but that these connections are really used. And 20k TPS is just the maximum amount that database node was able to handle. To bump tps we had to spin up more db replicas. We want to run these tests as well at some point, but now were just verifying that we can connect millions of clients and with some tangible tps but not overcomplicating the setup too much.

by jhgg 4y ago

chasers 4y ago

Nice! Yeah really our first go at it so I’m sure we have room to improve. PgBouncer was on the same instance I’m assuming?

jhgg 4y ago
nah we run a pool of common pgbouncers that route to the various postgres instances we run. they also run google's cloud sql proxy as well. it's actually haproxy -> pgbouncer -> cloud sql proxy -> postgres. everything but postgres runs on one machine. we use haproxy to load balance replica connections across different pgbouncer backends for replicas of the same db.
- chasers 4y ago
  Ha! Wait but why Google Cloud SQL proxy too? If you are interested in connecting over this it would be great to connect… chase@supabase.com. We want to do load balancing too. Makes so much sense to do load balancing in the proxy.
  - jhgg 4y ago
    cloud sql proxy makes connecting to cloud managed postgres instances pretty simple/easy. honestly, we dont have a "great" reason other than, we set it up a long time ago, and it's continued to work haha. so pgbouncer connects to cloud sql proxy, which does the connection pooling concern.

egorr 4y ago

Hey, from what we’ve seen up to 50k per node should be ok for supavisor on 4 cores as well. And TPS is here mainly to demonstrate that we not only create dummy connections but that these connections are really used. And 20k TPS is just the maximum amount that database node was able to handle. To bump tps we had to spin up more db replicas. We want to run these tests as well at some point, but now were just verifying that we can connect millions of clients and with some tangible tps but not overcomplicating the setup too much.