On 10/23/2013 04:28 PM, Jeff Janes wrote:
My page response time is sub-second, and I run quite a few queries to build the page. But also, my server isn't to busy at the moment. The load is around 0.3 to 0.5 when its busy.
Wasn't your question to figure out how to make sure things continue to run fine when the demand increases to a higher level than it currently is? If you cite its current OK performance to reject the advice, I'm not really sure what we are going to accomplish.
Correct, my current load and response time are fine, but I'll be getting more load soon. I didn't reject the advice. I installed pgbouncer on my test box, played with it, then installed it on the live box and let it run live for a while, until I ran into problems, then shut it off.
Although there are a few new players. Assuming Apache, pgbouncer and postgres are all on the same box, and I'm using unix sockets as much as possible, it probably doesn't matter if I use non-persistent connections from php.
But if I need to move the db to its own box... then should I move pgbouncer there too?
That depends on where the bottleneck is.
That's my big problem. I don't have a bottleneck now, and I'm trying to guess (without experience) where the bottleneck will be. Judging by everyone's response, pg_connect will be a bottleneck that I'll have to try and find a solution for.
Google did turn up some links about why you might put pgbouncer on web box vs. db box. Thats all well and good, except I'm not sure I can even use pgbouncer as my magic pill. It doesn't work so well with lots of databases. And I have lots of code and batch processes in place so its not gonna be simple to use a single db with lots of schemas.
I'm still undecided on what to do, or if I should even do anything at all. I am grateful for all the advice though.
-Andy
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
