mike503 at gmail.com
Thu Mar 5 07:53:48 MSK 2009
On Mar 4, 2009, at 12:34 PM, Roger Hoover <roger.hoover at gmail.com>
> 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
> >> this will require congestion notifications from the web server,
> >> you said)
> > Functionality was recently added to supervisord to modify it's
> > 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
> 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..
> 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...
More information about the nginx