From new-httpd-owner-new-httpd-archive=hyperreal.org@apache.org Fri Apr 02 11:22:01 1999 Return-Path: Delivered-To: new-httpd-archive@hyperreal.org Received: (qmail 3108 invoked by uid 6000); 2 Apr 1999 11:21:59 -0000 Received: (qmail 3099 invoked from network); 2 Apr 1999 11:21:56 -0000 Received: from ecpport2.ecopost.com.au (HELO ecpport2.midcoast.com.au) (203.28.64.15) by taz.hyperreal.org with SMTP; 2 Apr 1999 11:21:56 -0000 Received: from midcoast.com.au (kmidc65-76.ecopost.com.au [203.28.65.76]) by ecpport2.midcoast.com.au (8.9.1/8.8.5) with ESMTP id VAA03283 for ; Fri, 2 Apr 1999 21:21:25 +1000 Message-ID: <3704BB3A.FA1D52E1@midcoast.com.au> Date: Fri, 02 Apr 1999 12:42:34 +0000 From: "Michael H. Voase" X-Mailer: Mozilla 4.06 [en] (X11; I; Linux 2.0.36 i486) MIME-Version: 1.0 To: new-httpd@apache.org Subject: Re: cgi performance in Apache-apr. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: new-httpd-owner@apache.org Precedence: bulk Reply-To: new-httpd@apache.org 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 : http://www.midcoast.com.au/~mvoase 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 http://www.midcoast.com.au/~mvoase | [ ] | Michael H. Voase. Director. ~~~~~~~~~~~~~~ The only difference between a car salesman and a computer salesman is that the car salesman knows he's lying . ----------------------------------------------------------------------------