FCGI.pm ?

[mike]

Hmm. Well

On Mar 4, 2009, at 12:34 PM, Roger Hoover <roger.hoover at gmail.com>  
wrote:

>
>
> On Wed, Mar 4, 2009 at 11:51 AM, mike <mike503 at gmail.com> wrote:
> On Wed, Mar 4, 2009 at 9:03 AM, Roger Hoover  
> <roger.hoover at gmail.com> wrote:
>
> >>  - dynamic pool size management (keep 1-5 running depending on  
> load;
> >>   this will require congestion notifications from the web server,  
> like
> >>   you said)
> >
> > Functionality was recently added to supervisord to modify it's  
> configuration
> > dynamically through the XML-RPC api so this is matter of  
> implementing the
> > load logic in an nginx plugin and making calls to supervisord to  
> add and
> > subtract from the pool.
>
> While I would like to keep my software stack low, this sounds like a
> neat benefit. Would just need to define hard upper limits, and how
> long to wait or whatever to kill spare/unused children (like apache, I
> suppose)
>
> Personally I would like to see a daemon that does this in itself.
> Leverages the fcgiwrap code + adds on features. I suppose it would
> have to be 'aware' of how many connections it was servicing per pool
> which Grzegorz makes it sound like can be very hard... but then it
> could manage things dynamically.
>
> request comes in -> depending on what port/socket/etc. it checks the
> pool, determines if any children are open (if more needed, spawn like
> apache, maybe log a notice in the log), changes to proper uid/gid if
> configured, then executes the fastcgi stuff, if it gets back an error,
> determine whether or not to log it, pass it back with the same http
> code, do both, etc..
>
>
> etc.
>
> The approach you describe assumes that the parent process can  
> intercept socket connections as they come in.  I don't think this is  
> possible within the constraints of the FastCGI spec.  Each FastCGI  
> process is forked with file descriptor 0 pointing to a shared  
> FastCGI socket and each child process just calls accept() on that  
> socket.  The OS is responsible to determining which process in the  
> pool accepts each request so there's no way for the parent process  
> to keep track of which child is taking which request.  Unless that  
> information can be retrieved from the kernel, I think the only place  
> that load logic can be implemented is in an nginx module.
>
>
>
> I don't understand enough about sockets, C, threading/forking/event
> models/etc. to see if that is even an option but it seems like it
> could be done, just not sure if it would be way too slow or not?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20090304/fb22c614/attachment.html>