Kevin Barnard wrote:
> I am generally interested in a good solution for this. So far our
> solution has been to increase the hardware to the point of allowing
> 800 connections to the DB.
>
> I don't have the mod loaded for Apache, but we haven't had too many
> problems there. The site is split pretty good between dynamic and
> non-dynamic, it's largely Flash with several plugins to the DB.
> However we still can and have been slammed and up to point of the 800
> connections.
>
> What I don't get is why not use pgpool? This should eliminate the
> rapid fire forking of postgres instanaces in the DB server. I'm
> assuming you app can safely handle a failure to connect to the DB
> (i.e. exceed number of DB connections). If not it should be fairly
> simple to send a 503 header when it's unable to get the connection.
>
Note, that I am not necessarily looking for a PostgreSQL solution to the
matter. Just a way to prevent the database from killing off the server
it sits on, but looking at the load averages.
I have attempted to make use of pgpool and have had some very poor
performance. There were constant error messages being sounded, load
averages on that machine seemed to skyrocket and it just seemed to not
be suited for my needs.
Apache::DBI overall works better to what I require, even if it is not a
pool per sey. Now if pgpool supported variable rate pooling like
Apache does with it's children, it might help to even things out. That
and you'd still get the spike if you have to start the webserver and
database server at or around the same time.
Martin Foster
Creator/Designer Ethereal Realms
martin@ethereal-realms.org
