On Wed, Sep 19, 2012 at 04:43:17PM +0200, Uriel wrote: > On Wed, Sep 19, 2012 at 4:10 PM, Stephen Paul Weber > <singpol...@singpolyma.net> wrote: > > Somebody claiming to be Uriel wrote: > >> > >> CGD runs as a FastCGI wrapper (to be used with nginx or similar web > >> server) or as a standalone HTTP server, handing over all requests to a > >> given CGI script. > > > > > > Is this just a wrapper for compatability (which seems odd, since most > > servers also speak CGI), or does it do prefork stuff to improve performance? > > Sadly not all servers speak CGI this days, most notably nginx, and > others often have broken CGI support. > > Also CGD can act as a extremely minimal HTTP server itself to directly > host "stand-alone" CGI scripts without a 'real' web server. > > The server itself uses goroutines which are very efficient, so has no > need to pre-fork, the called CGI script can't be 'preforked' because > before you fork a CGI script you have to set the relevant environment > variables for the request. > > Still, forking is never the bottleneck (werc itself performs hundreds > of fork per request) and I wouldn't be surprised if CGD is not more > efficient than the CGI-handling code in most web servers, but if your > web server already supports CGI i wouldn't really bother.
I read somewhere that forking looks like a problem in combination with multithreaded webservers, since all threads are cloned, in order to be thrown away after during exec'd. And so FCGI deamons emerged: push the fork away from the threaded process. There seemed to be no need to use FCGI for single threaded webservers. Kurt
