httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: Scalability of mod_cgid
Date Thu, 27 Mar 2003 17:40:18 GMT
At 08:25 AM 3/27/2003, Jeff Trawick wrote:
>b) mod_cgi as a backup
>
>load both modules into the server, with mod_cgid getting the first shot

FWIW ... after accidently loading both into the server, ScriptLog wasn't
respected breaking the regressions.  Probably a bug in the config parser.

But these modules both read all the configs, so one will get a crack at
those directives, the other won't.

>with increasing numbers of threads per Apache child process we expect mod_cgi to be increasingly
slower, but to some extent (I think :) )
>a peak CGI load high enough to lead to failures with mod_cgid will "merely" cause a performance
hit with mod_cgi, and enough of this performance hit is in the right place (the handler, not
asynchronous processes like the cgid daemon) to act like flow control so that we won't continue
to pick up new requests as quickly until we catch up

There are other problems with fork()/exec() of a threaded Apache server
in terms of races around the registration of cleanups.  mod_cgi right now
isn't a really elegant solution.  I don't mind reviewing that code over the
next month to see that we register the cleanup and then open the object
(whatever that is, mutex, file, or whatnot.)  There will still be edge cases.

I liked your idea of a multiple cgid worker pool :-)



Mime
View raw message