atom feed39 messages in ru.sysoev.nginxRe: FCGI.pm ?
FromSent OnAttachments
Chris CorteseFeb 26, 2009 12:40 am 
mikeFeb 26, 2009 1:07 am 
Chris CorteseFeb 26, 2009 1:35 am 
Anoop AliasFeb 26, 2009 1:43 am 
Chris CorteseFeb 26, 2009 2:08 am 
Grzegorz NosekFeb 26, 2009 2:26 am 
Chris CorteseFeb 26, 2009 3:11 am 
Jim OhlsteinFeb 26, 2009 3:35 am 
Grzegorz NosekFeb 26, 2009 4:03 am 
mikeFeb 26, 2009 9:47 am 
Jim OhlsteinFeb 26, 2009 11:53 am 
Cliff WellsFeb 26, 2009 1:02 pm 
mikeFeb 26, 2009 2:19 pm 
Jim OhlsteinFeb 26, 2009 3:10 pm 
Chris CorteseFeb 27, 2009 2:31 am 
lubenFeb 27, 2009 6:11 am 
lubenFeb 27, 2009 6:40 am 
Grzegorz NosekFeb 28, 2009 4:17 am 
mikeFeb 28, 2009 2:03 pm 
Roger HooverMar 3, 2009 1:45 pm 
mikeMar 3, 2009 6:10 pm 
Roger HooverMar 3, 2009 8:08 pm 
Grzegorz NosekMar 4, 2009 12:40 am 
mikeMar 4, 2009 12:54 am 
Grzegorz NosekMar 4, 2009 1:42 am 
Jean-Philippe MoalMar 4, 2009 1:50 am 
mikeMar 4, 2009 2:14 am 
Roger HooverMar 4, 2009 9:03 am 
Roger HooverMar 4, 2009 9:23 am 
mikeMar 4, 2009 11:51 am 
Roger HooverMar 4, 2009 12:34 pm 
mikeMar 4, 2009 8:53 pm 
mikeMar 4, 2009 9:05 pm 
Roger HooverMar 5, 2009 9:22 am 
mikeMar 5, 2009 9:55 am 
Roger HooverMar 5, 2009 12:25 pm 
mikeMar 5, 2009 4:15 pm 
Roger HooverMar 6, 2009 5:21 pm 
mikeMar 6, 2009 6:16 pm 
Subject:Re: FCGI.pm ?
From:Roger Hoover (roge@gmail.com)
Date:Mar 4, 2009 12:34:00 pm
List:ru.sysoev.nginx

On Wed, Mar 4, 2009 at 11:51 AM, mike <mike@gmail.com> wrote:

On Wed, Mar 4, 2009 at 9:03 AM, Roger Hoover <roge@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?