> 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.
Thanks for the response.
To be clear, it sounds like you are advocating solving the problem with
scaling the number of connections with a different approach, by limiting
the number of web server processes.
So, the front-end proxy would have a number of max connections, say 200,
and it would connect to another httpd/mod_perl server behind with a
lower number of connections, say 20. If the backend httpd server was
busy, the proxy connection to it would just wait in a queue until it was
available.
Is that the kind of design you had in mind?
That seems like a reasonable option as well. We already have some
lightweight Apache servers in use on the project which currently just
serve static content.
Mark
