>So use mod_cgi :) > >(If there isn't a compelling performance difference, that makes sense >from Apache's perspective because mod_cgid is unfortunately >complicated >and it isn't worth more tricks if there's no sense in using it in the >first place.)
My understanding of the world is that mod_cgid is necessary for decent performance with worker threads.
That is what I've always been told. I just did a few very unscientific tests using the default worker MPM config (25 threads per child I think) and found that mod_cgi was consistently around 12.5% slower. Note that this was a test where all the server was doing was printenv.
Unfortunately I also found that mod_cgid was not at all reliable even for printenv, so potentially some of the performance boost was due to some cheap error paths.
Here's a sampling of stuff in the error log:
(9)Bad file number: write to cgi daemon process Premature end of script headers: printenv daemon couldn't find CGI process for connection 7 (232)Connection reset by peer: Error reading request on cgid socket (9)Bad file number: ap_content_length_filter: apr_bucket_read() failed
The "daemon couldn't find CGI process for connection 7" error probably has my name on it. I suspect some fatal error already occurred on the request and we neglected to avoid some later cleanup which, given the error, is not appropriate.
Just as supporting mod_cgi.c and mod_cgid.c adds to Apache maintenance work, for us to have to support both models would be prohibitive. Hence my desire for a good workaround.
Apache has to support both mod_cgi.c and mod_cgid.c anyway, broken [on] HP-UX or not. Your personal mileage may vary :)
If somebody doesn't care about local security, mod_cgid should be able to see something like
scriptsock 127.0.0.1:9999
in the config file and use a TCP socket instead of Unix socket for communication with the daemon.
Alternatively the handler could store the request body in a temporary file and have the daemon set the child's stdin to that temporary file.
Alternatively some sort of named pipe could be used instead of a Unix socket.
