I think FastCGI behind nginx is a highly scalable model. You get excellent performance via unix domain sockets and fault tolerance by the fact that the FastCGI processes are independent of the web server and that you can partition your traffic across pools of FastCGI processes listening on different sockets. If your application divides naturally into areas of functionality (say, API calls versus website traffic), you can route those to separate FastCGI sockets so that traffic backed up on one does not adversely affect the other (except perhaps at the DB level).<br>
<br>Under Apache, mod_fastcgi provided a process manager to monitor FastCGI daemons but that ties you to Apache + it's concurrency model (1 request per thread/process). With lighttpd and nginx, it seems like there's a hodge podge of solutions such as using cgi-fcgi or spawn-fcgi to spawn FastCGI processes but these don't have process management. Rails has utils called spinner, spawner, and reaper but these don't support unix domain sockets and only assign one ruby process per socket.<br>
<br>Supervisor (<a href="http://supervisord.org/">http://supervisord.org/</a>) provides a language/platform/framework-agnostic, full-service process manager (including restarts with backoff, groups of identical processes, remote management, pluggable event handling, and pluggable RPC customization) that can be used with any web server. I recently added support for managing FastCGI processes. The changes are in the trunk and not yet released as an official version.<br>
<br>Roger<br><br><div class="gmail_quote">On Thu, Jun 12, 2008 at 11:09 AM, Dan M <<a href="mailto:strangepics@gmail.com" target="_blank">strangepics@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>On Thu, Jun 12, 2008 at 4:24 AM, Manlio Perillo<br>
<<a href="mailto:manlio_perillo@libero.it" target="_blank">manlio_perillo@libero.it</a>> wrote:<br>
<br>
> This can not be generalized.<br>
<br>
</div>Of course it can. There are bad designs, and there good designs.<br>
Apache's mod_* is an example of bad design from the viewpoint of<br>
security and reliability. The modules are loaded into the web server.<br>
If one of the modules is compromised or buggy the whole system is<br>
compromised or buggy. Also large amounts of RAM need to be used for<br>
all the mod_*. Also the security boundaries cannot be set between<br>
modules because they're just one process. The analogy can be made<br>
between Sendmail and qmail. Sendmail is monolithic and not modular.<br>
qmail is modular. Look how many exploits Sendmail had... Sendmail is<br>
also slow and hard to administer.<br>
<div><br>
> The main problem is that separating the main server from the application<br>
> server means that you need to implement another server!<br>
<br>
</div>Yes, and that's GOOD - modular design.<br>
<div><br>
> Implementing a robust/scalable/efficient server is not an easy task, so<br>
> using mod_whatever is the best solution (assuming, of course, that the<br>
> application is designed to taking advantage of being embedded in a server).<br>
<br>
</div>It's not, you are just hung up on this idea for some reason. I think<br>
you may be thinking that mod_* is MUCH faster, while in reality it's<br>
not that much faster. If you weigh benefits vs. risks it's not worth<br>
it. Web servers are web servers, and applications are applications.<br>
This is also the original UNIX mantra (many little programs each doing<br>
its specific little purpose) that Apache and Sendmail do not follow.<br>
<br>
--<br>
<font color="#888888">Dan<br>
<br>
</font></blockquote></div><br>