When traffic to our PostgreSQL-backed website spikes, the first resource
we see being exhausted is the DB slots on the master server (currently
set to about 400).
I expect that as new Apache/mod_perl children are being put to us, they
are creating new database connections.
I'm interested in recommendations to funnel more of that traffic through
fewer DB slots, if that's possible. (We could also consider increasing
the handles available, since the DB server has some CPU and memory to
spare).
I'm particularly interested in review of DBD::Gofer, which seems like it
would help with this in our Perl application:
http://search.cpan.org/dist/DBI/lib/DBD/Gofer.pm
I realize it has limitations, like "no transactions", but I think we
would still able to use it selectively in our application.
Under heavy load, Apache has the usual failure mode of spawning so many
threads/processes and database connections that it just exhausts all the
memory on the webserver and also kills the database.
As usual, I would use lighttpd as a frontend (also serving static files)
to handle the large number of concurrent connections to clients, and then
have it funnel this to a reasonable number of perl backends, something
like 10-30. I don't know if fastcgi works with perl, but with PHP it
certainly works very well. If you can't use fastcgi, use lighttpd as a
HTTP proxy and apache with mod_perl behind.
Recipe for good handling of heavy load is using an asynchronous server
(which by design can handle any number of concurrent connections up to the
OS' limit) in front of a small number of dynamic webpage generating
threads/processes.
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
