httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael H. Voase" <>
Subject Re: cgi performance in Apache-apr.
Date Fri, 02 Apr 1999 12:42:34 GMT
Ryan Bloom wrote:
> 2)  We could fork a new process during the initializer phase of the cgi
> module, and using pipes (named and unnamed), pass enough information to
> the process to allow it to fork the cgi process.  Hopefully, process will
> be small enough that it will cost less to fork and send data to it than it
> will to fork a multi-threaded process.  Basically, the flow is:
>      monitor server sets up a group of named pipes in /tmp/apache
>      monitor server forks the cgi server and sets up unnamed pipe to it.
>      monitor then forks all the children servers, which inherit the pipe.
>      when a cgi request comes in, it picks a named pipe, and tells the cgi
>        server which one it is using through the unnamed pipe.
>      the two servers open the named pipe, and the web server sends all
>        need information to the cgi server (uri, filename, args, etc.)
>      The cgi server executes the cgi after having set std(in|out|err) to
>        the correct named pipes.
> I see one problem with this implementation, and could use some help.  

	Well , this excerpt sounds a lot like mod_cgisock with a few 
differences . The cgisock module uses a unix domain socket to connect
apache to the script . Note that cgisock is still in beta so isnt a
completed work by any means . Anyways if you want to use it under APR
you would have to remove the timeout calls in the module so that
it will compile ( I have tinkered cgisock under APR and I have 
had it running ) . A note here though that there are some 
conceptual differences between mod_cgi and mod_cgisock that doesnt fit 
with what youre looking for ... particularly -

	It doesnt handle any std_error info from the script . Its
design was intended originally for a CGI server that is independent
of Apache and sets up its own error logs ( one day I may actually 
write this server when I get the time ;-). 
	The scripts on the other end of the sockets have a lot more
to do than simply sitting in a directory passively waiting for a
server to run them . This is a pain for script writers until I
get CGIServer off the ground ....

	It leans fairly heavilly on select() to complete
its duties . I know that this is considered bad .

	Anyways now that I have had me rant , if you want to
have a look at it , it lives at :

	Lastly , it seems to me that to work around these
issues that you have discovered in these platforms Ryan , 
you have to end up bending over backwards to accomidate
them . mod_cgisock is my take on a solution for persistent
scripts , it certainly is not intended as a solution for
this problem nor is it as elegant or as capable
as many of its counterparts ( read : mod_perl , 
mod_fastcgi , mod_php et al ) but it handles a multithreaded
environment well since it doesnt utilise a lot of things that 
makes mod_cgi bad on the platforms you have found , ie no chdir()
and no ap_create_child . Also it has the basic necesities 
required to get a base CGI 1.1 script running . The most
important piece of information is the environment variables
which must be fed to the script so that it knows the
details of the request . In cgisock , I have a small 
routine that assembles the variables as a \n seperated
list that gets fed down the tube . If youre going to head
down the road of starting a seperate process to handle
requests , then cgisock might make a good read as to what
youre in for when playing CGI over pipes and sockets ...

Cheers Mik Voase.	

 /~\     /~\            CASTLE INDUSTRIES PTY. LTD.
 | |_____| |            Incorporated 1969. in N.S.W., Australia
 |         |            Phone +612 6562 1345 Fax +612 6567 1449
 |   /~\   |            Web
 |   [ ]   |            Michael H. Voase.  Director.
~~~~~~~~~~~~~~          The only difference between a car salesman and
a computer salesman is that the car salesman knows he's lying .

View raw message