httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject Re: cgid on hp-ux - read hangs because shutdown doesn't close
Date Fri, 07 Mar 2003 16:37:15 GMT
> >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.


Mime
View raw message