httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject Re: Scalability of mod_cgid
Date Thu, 27 Mar 2003 14:25:58 GMT
Steve Sabljak wrote:
> 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


Mime
View raw message