mod_rails aka mod_rack aka mod_ruby

[Roger Hoover]

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).

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.

Supervisor (http://supervisord.org/) 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.

Roger

On Thu, Jun 12, 2008 at 11:09 AM, Dan M <strangepics at gmail.com> wrote:

> On Thu, Jun 12, 2008 at 4:24 AM, Manlio Perillo
> <manlio_perillo at libero.it> wrote:
>
> > This can not be generalized.
>
> Of course it can. There are bad designs, and there good designs.
> Apache's mod_* is an example of bad design from the viewpoint of
> security and reliability. The modules are loaded into the web server.
> If one of the modules is compromised or buggy the whole system is
> compromised or buggy. Also large amounts of RAM need to be used for
> all the mod_*. Also the security boundaries cannot be set between
> modules because they're just one process. The analogy can be made
> between Sendmail and qmail. Sendmail is monolithic and not modular.
> qmail is modular. Look how many exploits Sendmail had... Sendmail is
> also slow and hard to administer.
>
> > The main problem is that separating the main server from the application
> > server means that you need to implement another server!
>
> Yes, and that's GOOD - modular design.
>
> > Implementing a robust/scalable/efficient server is not an easy task, so
> > using mod_whatever is the best solution (assuming, of course, that the
> > application is designed to taking advantage of being embedded in a
> server).
>
> It's not, you are just hung up on this idea for some reason. I think
> you may be thinking that mod_* is MUCH faster, while in reality it's
> not that much faster. If you weigh benefits vs. risks it's not worth
> it. Web servers are web servers, and applications are applications.
> This is also the original UNIX mantra (many little programs each doing
> its specific little purpose) that Apache and Sendmail do not follow.
>
> --
> Dan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20080612/223e5c20/attachment.html>