or nginx + supervisord + v8cgi ^^ (that i haven't try that yet..)<br><br><div class="gmail_quote">On Wed, Oct 21, 2009 at 2:42 PM, Phillip Oldham <span dir="ltr"><<a href="mailto:phill@activityhq.com">phill@activityhq.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">Grzegorz Nosek wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Like fellow posters said, spawning processes by the web server is not<br>
a good idea (especially by a lean and mean server like Nginx). What<br>
we're using (or at least migrating to) is supervisord[1] for process<br>
management and a custom Nginx module for integration. We have Nginx<br>
communicate with supervisord over XMLRPC to start/shutdown processes as<br>
directed by the load balancer. Supervisord provides process management<br>
way above Nginx could offer, while Nginx provides load data in real<br>
time, so we have exactly as many backends as we need.<br>
<br>
If you aim for simply running a pool of backends, look at supervisord,<br>
period.<br>
<br>
If you also want to size the pool dynamically, watch this space :)<br>
ngx_supervisord isn't yet available (still waiting for finishing<br>
touches) but consider this a pre-announcement. It's going to require<br>
patches to the load balancer but if you're using upstream-fair, the<br>
patch comes with the module source.<br>
<br>
</blockquote></div>
Wonderful! This sounds just what we're looking for too. I've been chatting with the maintainers over at supervisord list (Roger et al) and they're aiming for another update in the coming weeks that may fix some issues with FCGI handling, which should make nginx + supervisord + php a very reliable platform.<br>
<br>
</blockquote></div><br>