<br><br><div class="gmail_quote">On Thu, Mar 5, 2009 at 4:15 PM, mike <span dir="ltr"><<a href="mailto:mike503@gmail.com" target="_blank">mike503@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I guess I would be more than happy then to stop using php-fpm and use<br>
this new tool.<br>
<br>
However I do like the benefits of php-fpm like the ability to override<br>
some php.ini directives.<br>
</blockquote><div><br>This seems like something that still appropriate for PHP's FCGI wrapper, even if that wrapper no longer needs to manage pools of processes.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Perhaps we should get Grzegorz (fcgiwrap), Andrei (php-fpm) and others<br>
together for this.<br>
</blockquote><div><br>I'd love to see if there's interest in this idea.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
A generic fastcgi to (php|cgi|ruby|python|whatever) interface ?</blockquote><div><br>A language-agnostic FastCGI process manager? One process manager to rule them all and in darkness bind them. :)<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<div><div></div><div><br>
On Thu, Mar 5, 2009 at 12:26 PM, Roger Hoover <<a href="mailto:roger.hoover@gmail.com" target="_blank">roger.hoover@gmail.com</a>> wrote:<br>
><br>
><br>
> On Thu, Mar 5, 2009 at 9:56 AM, mike <<a href="mailto:mike503@gmail.com" target="_blank">mike503@gmail.com</a>> wrote:<br>
>><br>
>> Sure - you mean anything that nginx (or any other server) speaks fastcgi<br>
>> to<br>
><br>
> Yes!<br>
><br>
>><br>
>> webserver <-> this process manager <-> code (perl cgi, or anything else) ?<br>
>><br>
>> Wouldn't this also be able to replace php-fpm then?<br>
><br>
> Ideally, yes. Even with PHP's unique lifecycle (all objects discarded after<br>
> each request), I don't see a reason why process pool management needs to be<br>
> built in to PHP FastCGI handling. Each PHP process could manage the request<br>
> lifecycle for itself while the process pool management could be handled<br>
> generically, just like any other language.<br>
><br>
>><br>
>> It seems like there are already ways using Tomcat/etc. for java,<br>
>> php-fpm for PHP, ruby and python have managers, but CGI does not. Can<br>
>> you give an example of what other things you'd want this to manage?<br>
><br>
> In short, I'd be happy if it exactly matched the process management features<br>
> of mod_fastcgi for Apache. mod_fastcgi does both FastCGI proxying and<br>
> process management. Nginx + other event driven webservers implement the<br>
> FastCGI proxying piece but not the process management piece.<br>
><br>
> You're right that each language seems to have a different way of managing<br>
> processes. This is appealing when all the infrastructure you run is in a<br>
> single language. If you run ruby, you do it "the ruby way". However, the<br>
> organizations I've worked for need to run code in different languages, for<br>
> various reasons including aquisition or migration. I think everyone would<br>
> benefit from a language agnostic process manage similar to mod_fastcgi but<br>
> not tied to Apache.<br>
><br>
>><br>
>> On Thu, Mar 5, 2009 at 9:22 AM, Roger Hoover <<a href="mailto:roger.hoover@gmail.com" target="_blank">roger.hoover@gmail.com</a>><br>
>> wrote:<br>
>> > This is an interesting idea. I'd like to see a generic process manager<br>
>> > come<br>
>> > out of the effort though, not just one that only works for wrapping<br>
>> > CGI. It<br>
>> > would be a great separation of concerns. The CGI wrapper could focus<br>
>> > on a<br>
>> > single task: accepting FastCGI requests and forking CGI processes to<br>
>> > handle<br>
>> > them. Process pool management could be handled by a generic FastCGI<br>
>> > process<br>
>> > manager, which could manage fcgiwrap pools and any other type of FastCGI<br>
>> > processes.<br>
>> ><br>
>> > On Wed, Mar 4, 2009 at 9:05 PM, mike <<a href="mailto:mike503@gmail.com" target="_blank">mike503@gmail.com</a>> wrote:<br>
>> >><br>
>> >> I am going to start a cgi-fpm project. The goals will be aligned like<br>
>> >> php-fpm except slightly modified for the differences with cgi and<br>
>> >> fastcgi.<br>
>> >> It might not be able to support adaptive spawning without some sort of<br>
>> >> api<br>
>> >> or tools but at least will make management easier and not require third<br>
>> >> party tools. It will basically enhance fcgiwrap with php-fpm style<br>
>> >> configuration and hooks for external control for things like an nginx<br>
>> >> module.<br>
>> >><br>
>> >> The annoyances with cgi and fastcgi can be discussed and hopefully<br>
>> >> addressed.<br>
>> >> Thoughts?<br>
>> >> Also this could just be an nginx module too. But it would add some<br>
>> >> weight<br>
>> >> and require suexec type stuff. So probably not a good idea.<br>
>> >> Let me throw together a quick list of ideas.<br>
>> >> On Mar 4, 2009, at 12:34 PM, Roger Hoover <<a href="mailto:roger.hoover@gmail.com" target="_blank">roger.hoover@gmail.com</a>><br>
>> >> wrote:<br>
>> >><br>
>> >><br>
>> >><br>
>> >> On Wed, Mar 4, 2009 at 11:51 AM, mike <<a href="mailto:mike503@gmail.com" target="_blank">mike503@gmail.com</a>> wrote:<br>
>> >>><br>
>> >>> On Wed, Mar 4, 2009 at 9:03 AM, Roger Hoover <<a href="mailto:roger.hoover@gmail.com" target="_blank">roger.hoover@gmail.com</a>><br>
>> >>> wrote:<br>
>> >>><br>
>> >>> >> - dynamic pool size management (keep 1-5 running depending on<br>
>> >>> >> load;<br>
>> >>> >> this will require congestion notifications from the web server,<br>
>> >>> >> like<br>
>> >>> >> you said)<br>
>> >>> ><br>
>> >>> > Functionality was recently added to supervisord to modify it's<br>
>> >>> > configuration<br>
>> >>> > dynamically through the XML-RPC api so this is matter of<br>
>> >>> > implementing<br>
>> >>> > the<br>
>> >>> > load logic in an nginx plugin and making calls to supervisord to add<br>
>> >>> > and<br>
>> >>> > subtract from the pool.<br>
>> >>><br>
>> >>> While I would like to keep my software stack low, this sounds like a<br>
>> >>> neat benefit. Would just need to define hard upper limits, and how<br>
>> >>> long to wait or whatever to kill spare/unused children (like apache, I<br>
>> >>> suppose)<br>
>> >>><br>
>> >>> Personally I would like to see a daemon that does this in itself.<br>
>> >>> Leverages the fcgiwrap code + adds on features. I suppose it would<br>
>> >>> have to be 'aware' of how many connections it was servicing per pool<br>
>> >>> which Grzegorz makes it sound like can be very hard... but then it<br>
>> >>> could manage things dynamically.<br>
>> >>><br>
>> >>> request comes in -> depending on what port/socket/etc. it checks the<br>
>> >>> pool, determines if any children are open (if more needed, spawn like<br>
>> >>> apache, maybe log a notice in the log), changes to proper uid/gid if<br>
>> >>> configured, then executes the fastcgi stuff, if it gets back an error,<br>
>> >>> determine whether or not to log it, pass it back with the same http<br>
>> >>> code, do both, etc..<br>
>> >>><br>
>> >>> etc.<br>
>> >><br>
>> >> The approach you describe assumes that the parent process can intercept<br>
>> >> socket connections as they come in. I don't think this is possible<br>
>> >> within<br>
>> >> the constraints of the FastCGI spec. Each FastCGI process is forked<br>
>> >> with<br>
>> >> file descriptor 0 pointing to a shared FastCGI socket and each child<br>
>> >> process<br>
>> >> just calls accept() on that socket. The OS is responsible to<br>
>> >> determining<br>
>> >> which process in the pool accepts each request so there's no way for<br>
>> >> the<br>
>> >> parent process to keep track of which child is taking which request.<br>
>> >> Unless<br>
>> >> that information can be retrieved from the kernel, I think the only<br>
>> >> place<br>
>> >> that load logic can be implemented is in an nginx module.<br>
>> >><br>
>> >>><br>
>> >>> I don't understand enough about sockets, C, threading/forking/event<br>
>> >>> models/etc. to see if that is even an option but it seems like it<br>
>> >>> could be done, just not sure if it would be way too slow or not?<br>
>> >>><br>
>> >><br>
>> ><br>
>> ><br>
>><br>
><br>
><br>
<br>
</div></div></blockquote></div><br>