Currently with apache 2.0.43 (64 bit, Solaris 8, worker mpm), under high load, we're seeing lots of connection refused to the cgi daemon in the error log.
Am I right in saying mod_cgid forks new processes as they're required? Would a pre-forking cgi daemon be worth implementing?
yes, both mod_cgi and mod_cgid fork a new process per cgi invocation... something like mod_fastcgi doesn't have to fork every time
preforking a new cgi script process, ready to exec the desired program would presumably work... the preforked child would need to be able to accept the request from the cgid handler instead of the cgid daemon (when a preforked child was available) or the request would always go to the cgid handler and it would forward it to a preforked child if there were one ready)
a couple of alternative ideas that might be simpler to implement:
a) multiple cgid daemons
each listens on different unix socket (logs/cgisock.1, logs/cgisock.2, etc.); cgid handler does round-robin when selecting which cgid daemon to send the request to
b) mod_cgi as a backup
load both modules into the server, with mod_cgid getting the first shot
if something fails in the handler (unable to connect to the daemon), let cgid DECLINE the request so that mod_cgi handles it
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
