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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
