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 :-)
