We did some very informal performance numbers for cgi's in the hybrid
server on AIX, and we have found a problem.  The performance for AIX went
downhill quickly when we tried running CGI scripts.  The reason for this,
is that fork on AIX creates the full address space for the process.  This
means, all of the threads are created and set to inactive.  This is a BIG
performance hit.  This problem is also known to exist on Sun, although
they fixed it for the most part.  I have a few solutions.

1)  Sun fixed it by providing a fork1 function, which only creates one
thread when it forks a multi-threaded process.  Not all Unix's have this
function, and those that do don't always call it the same thing.  We could
create an ap_fork call and #define it for the Unix's that have a good fork
function, but that still doesn't solve the problem for all Unix's.

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.  The
cgi module calls ap_call_exec to execute the script.  The first thing this
function does, is call ap_get_module_config to get the core modules config
fot RLIMIT stuff.  This requires the per_dir_config structure in the
request_rec.  I have a very sparsly filled out request_rec from
information sent through the pipes, but I can't send that linked list down
the pipe.  This causes the server to crash horribly.

I have two solutions and I hate them both, so I am hoping somebody else
might have a better one.

1)  Figure out which fields are required in the core_module strucure, and
hack them into the cgi module.  For example, create a config structure
with the same module number as core_module and limit_cpu, limit_nproc,
etc.  Store that structure in r->per_dir_config.  This is a hack beyond
all belief.  I really don't like hacks.  I _should_ work though.

2)  Re-implement ap_call_exec in the new cgi module and get rid of
anything from the module_config call.  This limits what we can do, and it
means our cgi's in the hybrid model aren't as configurable as they were in
1.3.

I want to stress, that for well behaved OS's, like Linux (although this
may not be true on 2.2), we can use the regular old mod_cgi.c, and we
should.  I am only concerned about those annoying really bad platforms.

Ryan


_______________________________________________________________________
Ryan Bloom		rbb@raleigh.ibm.com
4205 S Miami Blvd	
RTP, NC 27709		It's a beautiful sight to see good dancers 
			doing simple steps.  It's a painful sight to
			see beginners doing complicated patterns.