On Wed, 13 Nov 2002, Björn Metzdorf wrote:
> > (only a little, of course). I know the bes approach is connection
> > pooling, but in some enviroments (php+apache) it's too dificult to
> > implement.
>
> What about php persistent connections? What exactly do you mean with
> connection pooling?
The problem lies with PHP/Apache's methods of persistant connections.
When you use persistant connections in PHP/Apache, what happens is that
each apache child process maintains its own individual persistant
connection. I.e. there is no "pool" like in JSP or AOLServer.
So, if you have an apache server set to provide 150 child processes (the
default I believe) and you get enough connects to actually have that many
all running at once, then each child process holds open a database
connection until it is terminated. So that means that the database has to
have that many backend processes up and running as well.
Since it's not uncommon to see postgresql configured for <150 child
processes, what eventually happens on a default apache/php/postgresql
setup (postgresql defaults to 32 child processes) is that after the 32nd
persistant connection, the next user gets an error message from PHP that
it couldn't connect to the database.
Now, the thing that makes this MUCH worse is if you have apache set to use
keep alive as well as a large number of children. When apache is set to
keep alive, each client maintains reconnects to the same apache child, and
that child won't answer other client requests until the max number of
child processes have been spawned.
So, if you want to use persistant connections with PHP/Apache, then
configure apache for something like 50 child processes, Postgresql for
about 100, and turn off http keep alive. That will usually work pretty
well.
