httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Sutherland <>
Subject Re: Performance comparison of mod_cgi and mod_cgid.
Date Mon, 12 Jun 2000 22:09:03 GMT
On Mon, 12 Jun 2000 wrote:

> > mod_cgid:
> >    Accept on server socket.
> >    Fork the child
> >    exec the cgi
> > 
> > mod_cgi:
> >    ap_createprocattr_init
> >    ap_setprocattr_io
> >    ap_setprocattr_dir
> >    ap_setprocattr_cmdtype
> >    ap_create_process
> >       fork child
> >       exec cgi
> >    ap_note_subprocess
> > 
> > The other processing before and after the above code is
> > very similar between the two. The exception might be in the way
> > that mod_cgi does iol handling vs. mod_cgid.
> I have a hard time with this explanation.  If you take a look at what the
> setprocattr_* functions are doing, it just isn't that much.  I also find
> it hard to believe that the cmdtype and dir functions can't be removed.
> This explanation really makes it look like APR is a huge drain on system
> resources, which is not what we are seeing with the rest of Apache 2.0.  I
> would prefer that we had some real proof that APR is causing these
> problems before this is just assumed.
> The original problem this module was meant to solve (namely forking a
> threaded process) seems like a much better explanation for the performance
> difference IMHO.  It seems to me that fork (on all platforms) must create
> all threads and then kill them all to be POSIX compliant.

I tend to agree with Ryan here; certainly fork() seems like the most
likely culprit, if it's forking a load of threads then killing them all
every time.

The next stage, of course, is to have the cgid process pre-fork, and add a
modular API. Then, after a few years, give it an abstraction layer to aid
porting, write multi-threaded versions... :-)

On a more serious note, have you tried moving the fork() up before the
accept(), so the child accept()s requests then exec()s? If it's possible,
this should help cut request latency slightly, I think? (Probably little
or no impact on these benchmarks, though...)


View raw message