4 ms·
We were big proponents of pgbouncer for years, but having one extra, sometimes capricious actor in our architecture ended up not being worth it. Especially if y
by akurilin 8y ago
We were big proponents of pgbouncer for years, but having one extra, sometimes capricious actor in our architecture ended up not being worth it. Especially if you're IO-heavy like we are, and that Web App -> DB pipe is the hottest path in the entire system.
Removing it altogether made monitoring and debugging performance issues easier, and client-side pools were essentially "good enough" for our purposes.
- Mizza 8y agoWere you managing your own DB server instance? I don't think client side pools are possible with RDS.
- akurilin 8y agoWe're on RDS right now. We use connection pools from https://www.yesodweb.com/book/persistent https://www.yesodweb.com/book/persistent
- Mizza 8y agoOhhh, I understand. Long day. I got that backwards, I thought there was a server-side option I wasn't aware of. So you don't have a dedicated server with PgBouncer on it, you just move the pooler to where the requests originates from. I think this might be problematic in a highly elastic/distributed architecture but would work if you have a beefy dedicated application instance.
- akurilin 8y agoCorrect, you'd have to instruct your pools to resize as machines are added and removed. We haven't had to do that so far, as we're not that dramatically elastic.