Forum: Mongrel Why Mongrel with NginX

96137eb50a2098ab4c56900f986ac610?d=identicon&s=25 John Hancock (hancock)
on 2008-08-08 18:35
Hi, I'm a newbie to Ruby. I'm installing an small server (256MB RAM)
with NginX, Neko, Perl, PHP4, PHP5, Ruby & MySQL. It's easy Perl, Neko &
PHP with FastCGI but why to use a mongrel cluster?

It's my first time with nginx & ruby, so why I should use mongrel?
Why not just FastCGI-ruby if available?
Is mongrel cluster too much load for 256MB RAM?

With PHP there is no security for shared servers. How does ruby handle
shared hosting security? Is there an appropriate way to install
ruby-mongrel this way?

Thanks
C98e88f3e69340d27466baadb2b80b4c?d=identicon&s=25 Gunnar Wolf (Guest)
on 2008-08-08 20:42
(Received via mailing list)
> Hi, I'm a newbie to Ruby. I'm installing an small server (256MB RAM)
> with NginX, Neko, Perl, PHP4, PHP5, Ruby & MySQL. It's easy Perl,
> Neko & PHP with FastCGI but why to use a mongrel cluster?

Because that's the way it works this side of reality ;-)

no, really, you could run most Ruby apps using different setups
(i.e. with FastCGI as you say), but it's actually much simpler to do
it via Mongrel.

> It's my first time with nginx & ruby, so why I should use mongrel?
> Why not just FastCGI-ruby if available?  Is mongrel cluster too much
> load for 256MB RAM?

It varies tremendously with the kind of applications you develope. I
will assume that, as is the case with most new Ruby webapps, you are
developing Rails. In my server, each Mongrel instance takes typically
between 20 and 50 MB RAM, for smallish applications. Of course, you
will probably have to add the Web server you choose (i.e. nginex) and
the RDBMS. However, running Mongrel clusters makes it easy, if not
trivial, to split the load among several machines. Yes, this is not
the _perfect_ way of scaling if your app load grows, but it is... good
enough :)

> With PHP there is no security for shared servers. How does ruby
> handle shared hosting security? Is there an appropriate way to
> install ruby-mongrel this way?

You can have many different models. PHP's main problem in this regard
is that it is most often run inside the Web server - so all instances
are run as the same user. You can do it differently, i.e. setting it
up via different FastCGI processes, but I'm talking about the general
case. With Mongrel, you can launch each instance as a different user -
The webserver just opens a socket to talk with Mongrel, but each
Mongrel can be owned by a different user, and get the user's set of
permissions.
96137eb50a2098ab4c56900f986ac610?d=identicon&s=25 John Hancock (hancock)
on 2008-08-08 21:41
> It varies tremendously with the kind of applications you develope. I
> will assume that, as is the case with most new Ruby webapps, you are
> developing Rails. In my server, each Mongrel instance takes typically
> between 20 and 50 MB RAM, for smallish applications.

In this scenario, I'll wait to get an other VPS because 2 mongrel
instances are taking more ram than the rest of the server. In the event
of high load my VPS will start killing any process because doesn't have
swap space.

What specs you would request for a ruby server (maybe just mongrel
cluster and mysql listening to the prior VPS)

> With Mongrel, you can launch each instance as a different user -
> The webserver just opens a socket to talk with Mongrel, but each
> Mongrel can be owned by a different user, and get the user's set of
> permissions.

So, a shared server is not the best approach for ruby (or getting the
same problems of PHP). Having 100 accounts with the corresponding
instance would be problematic.


Thank you
B984299ceb40752b58146714eb192554?d=identicon&s=25 ryah dahl (Guest)
on 2008-08-10 15:00
(Received via mailing list)
Hi John

On Fri, Aug 8, 2008 at 6:35 PM, John Hancock <lists@ruby-forum.com>
wrote:
> Hi, I'm a newbie to Ruby. I'm installing an small server (256MB RAM)
> with NginX, Neko, Perl, PHP4, PHP5, Ruby & MySQL. It's easy Perl, Neko &
> PHP with FastCGI but why to use a mongrel cluster?

The only conceptual difference is the protocol being used between the
reverse-proxy (nginx in this case) and the application servers.
FastCGI is a protocol for reverse-proxies to speak to application
servers.  FastCGI is strange because it carries HTTP but is not HTTP.
With a Mongrel-style setup your application servers speak to the
reverse-proxy via HTTP.

FastCGI has a slight advantage over HTTP in that it's easier to parser
and more space-efficient on the line. However it adds an extra layer
of complexity - an extra protocol. You can't, for example, use CURL to
access a FastCGI application server.

The structure is the same though - a load balancer reverse proxy
process (nginx) and many application server processes (mongrel or
FastCGI instances). The load balancer distributes requests to the app
servers - gets a responses and sends them back to the clients.

Mongrel has worked better for many of us - not because of the protocol
difference - because it handles requests better. Ruby-FastCGI is also
a web server and has request handling logic - it just speaks FastCGI
instead of HTTP.

Someone could develop a better Ruby-FastCGI binding which understood
FastCGI but handled connections from the reverse-proxy better - but
that hasn't been done yet. And IMO it is a bit pointless - there need
not be a special protocol just for communication between load
balancers and app servers.


ry
96137eb50a2098ab4c56900f986ac610?d=identicon&s=25 John Hancock (hancock)
on 2008-08-11 01:15
> Mongrel has worked better for many of us - not because of the protocol
> difference - because it handles requests better. Ruby-FastCGI is also
> a web server and has request handling logic - it just speaks FastCGI
> instead of HTTP.

The easier and useful answers are never given on documentation, thanks
everybody.
I'm just dropping Apache because it's not memory efficient and these
days with my question I've searching all about mongrel.
There is a new branch of the Ruby language called "Ruby Enterprise
Edition" that seems to use enough memory to fit in my VPS. The problem
is the server it uses, Apache. For me there is not value to reduce the
memory usage of ruby when it is done into a platform that is not memory
efficient. Is there an adaptation of mongrel to use ruby enterprise?

This is an awesome forum with awesome pals.
02f0ee0da223f90bb9996ef252e528c1?d=identicon&s=25 Hongli Lai (foobarwidget)
on 2008-08-11 14:01
John Hancock wrote:
> The easier and useful answers are never given on documentation, thanks
> everybody.
> I'm just dropping Apache because it's not memory efficient and these
> days with my question I've searching all about mongrel.
> There is a new branch of the Ruby language called "Ruby Enterprise
> Edition" that seems to use enough memory to fit in my VPS. The problem
> is the server it uses, Apache. For me there is not value to reduce the
> memory usage of ruby when it is done into a platform that is not memory
> efficient. Is there an adaptation of mongrel to use ruby enterprise?
>
> This is an awesome forum with awesome pals.

At the moment Mongrel can't use the copy-on-write optimizations provided
by Ruby Enterprise Edition.

As for Apache, it's possible to tweak it to lower its memory usage to
levels comparable to Nginx. The key lies in disabling all modules that
you don't need, and using the worker MPM instead of the default prefork
MPM, with settings comparable to Nginx's. The resulting memory usage is
described at http://www.rubyenterpriseedition.com/comparisons.html.
This topic is locked and can not be replied to.