roger.hoover at gmail.com
Thu Mar 5 20:22:51 MSK 2009
This is an interesting idea. I'd like to see a generic process manager come
out of the effort though, not just one that only works for wrapping CGI. It
would be a great separation of concerns. The CGI wrapper could focus on a
single task: accepting FastCGI requests and forking CGI processes to handle
them. Process pool management could be handled by a generic FastCGI process
manager, which could manage fcgiwrap pools and any other type of FastCGI
On Wed, Mar 4, 2009 at 9:05 PM, mike <mike503 at gmail.com> wrote:
> I am going to start a cgi-fpm project. The goals will be aligned like
> php-fpm except slightly modified for the differences with cgi and fastcgi.
> It might not be able to support adaptive spawning without some sort of api
> or tools but at least will make management easier and not require third
> party tools. It will basically enhance fcgiwrap with php-fpm style
> configuration and hooks for external control for things like an nginx
> The annoyances with cgi and fastcgi can be discussed and hopefully
> Also this could just be an nginx module too. But it would add some weight
> and require suexec type stuff. So probably not a good idea.
> Let me throw together a quick list of ideas.
> 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>
> mike503 at gmail.com> wrote:
>> On Wed, Mar 4, 2009 at 9:03 AM, Roger Hoover < <roger.hoover at gmail.com>
>> 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
>> > dynamically through the XML-RPC api so this is matter of implementing
>> > 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