Is mod_ruby still considered an inferior solution compared to fastcgi,
even after the availability of 1.2.6, which includes the
RailsDispatcher [1], which allows for safe execution of multiple rails
applications?
I’m asking because using apache is a requirement here, given our
existing set of tools which work with it. Also, mod_ruby doesn’t
require executable scripts, which allows me to mount the partition
with the noexec flag (this is an important security feature in a
server that allows customer logins via ssh).
Is mod_ruby still considered an inferior solution compared to fastcgi,
even after the availability of 1.2.6, which includes the
RailsDispatcher [1], which allows for safe execution of multiple rails
applications?
Both are inferior to mongrel. Even with the new mod_ruby, do you
really want to use something with a small enough user base that you
don’t know if it will still work a year down the road? And if you
allow ssl logins but don’t allow them to execute anything, what’s the
point?
It’s not that they can’t execute anything. It means they can’t have
executables in their home dirs.
And why is that bad again?
I’d hate to know I couldn’t execute my own backup.sh in my own ~
Presumably /bin/sh is on another partition so “/bin/sh backup.sh” would
work fine.
I’m just playing devil’s advocate
Back to the issue at hand: I am currently developing a Rails app which I
will be deploying in the next month or so. I was intending to use Apache
webserver because I am familiar with it but the comments in this thread
prompted me to take a look at Mongrel.
It appears that Mongrel doesn’t support SSL and “…will break down
pretty quick if you have lots of people accessing Rails actions that are
slow.” How can anyone seriously propose Mongrel for a production setup?
It appears that Mongrel is just a cut-down and easy-to-use webserver for
the kiddies who don’t want to learn Apache. The documentation makes
numerous statements like “Apache is notorious for having a horribly
complex configuration file.” What a load of bullshit! Sure, there are
lots of directives which can be a bit overwhelming for the newbie, but
break it down and look at each directive individually and it makes
perfect sense. There are some great books out there to help.
So to Andre, who started this thread: I’ll be trying mod_ruby so there’s
one more for the user base
Both are inferior to mongrel. Even with the new mod_ruby, do you
really want to use something with a small enough user base that you
don’t know if it will still work a year down the road?
Why not? If nobody starts using it, the userbase will never grow. I
guess rails itself had a small user base once… why did the pioneers
start using it?
And if you allow ssl logins but don’t allow them to execute anything, what’s the
point?
It’s not that they can’t execute anything. It means they can’t have
executables in their home dirs.
I wouldn’t be too quick to cast Mongrel to the dogs, as it were. It’s
running a number of fairly decent sized sites, including one of the
37s ones (http://weblog.rubyonrails.org/2006/7/3/pound-makes-lighty-
and-mongrel-play-nice). As distinctly opposed to where PHP and dot-
Net deployment is right now, Rails deployment is not a one-target
deal (IMO). There are several capable servers around that can serve
up pages, and many people have thrashed at all of them. The consensus
seems to be moving toward Apache proxying to a load balancer,
distributing to a Mongrel pack.
Mongrel packs will not break down “if you have lots of people…”
because you can add new Mongrel instances behind your load balancer.
Pages that are slow typically only take .2 seconds to serve up. If
you have 4-5 Mongrels running in a cluster, you’re unlikely to
experience latency as a result of a blocking request, but of course
some testing would be in order.
I run some of my sights on lighttpd and some on Mongrel. Now that
I’ve started using Mongrel, each lighttpd site that gets a revision
also changes to Mongrel. It’s that much easier to work with. I
haven’t even considered Apache because fcgi has typically been
unstable and mod_ruby suffered from concurrency problems.
It appears that Mongrel doesn’t support SSL and “…will break down
pretty quick if you have lots of people accessing Rails actions that are
slow.” How can anyone seriously propose Mongrel for a production setup?
That may be from the documentation, I’m not sure. Anyway, you’re
right that it doesn’t support SSL. Not sure why you’d need/want it
to. Mongrel, as far as I know, was developed from the ground up to be
a Rails server. If you need stuff like SSL, you use a web server that
supports SSL and uses mod_proxy to talk to Mongrel. Which it sounds
like you have in Apache
If you only have one Mongrel process, then yeah it’ll choke on
multiple requests to slow-running pages. That certainly doesn’t seem
like a fault of Mongrel though…any time you have a single thread of
access and really slow code you’re going to have trouble.
Now for my experience…I’ve been running pregopoker.com for the past
6 months, and it’s using Apache with mod_proxy to Mongrel. All the
static stuff is handled by Apache, as well as the SSL. I run it on
three mongrel processes, and it handles 80k requests/day with no
problem, the vast majority of them being handled by Mongrel. 80k
isn’t even a request/second…I’m not going to get into detailed stats
and standard deviations like Zed wants, mainly cause I just don’t care Mongrel runs great for my config. I’d have to say that most pages
are relatively slow…each request results in some fairly complex math
going on in the background. I can almost assure you that all my pages
run slower than yours will, and I’ve never run into a problem with
Mongrel breaking down under heavy access.
Mongrel’s also never crashed on me. Not once.
Long story short, Mongrel is not for kiddies. Mongrel is perfect for
hosting Rails apps, and runs great behind a full-featured webserver
for handling the other duties.
So to Andre, who started this thread: I’ll be trying mod_ruby so there’s
one more for the user base
Heh, nice Michael
I guess I should just try mongrel too and see how it goes compared to
mod_ruby. Anyone has hints on how to set up mongrel_cluster to serve
in a shared hosting environment? Can I set up a single cluster that
will receive connections to the different applications as needed, or
do I have to pre-allocate a static number of intances for each virtual
host?
Also, what’s a good way to calculate the needed number of mongrel
instances I’ll need? For example, in a mod_php server here there are
48 instances of Apache running simultaneously. If this was a rails
server with mongrel, would I need 48 instances of mongrel? Can this be
made dynamically (i.e., mongrel creates more instances as needed)?
Pointers to the appropriate docs would be great. I’ve searched them
and the list though, and couldn’t find much stuff related to shared
hosting.
I guess I should just try mongrel too and see how it goes compared to
mod_ruby. Anyone has hints on how to set up mongrel_cluster to serve
in a shared hosting environment? Can I set up a single cluster that
will receive connections to the different applications as needed, or
do I have to pre-allocate a static number of intances for each virtual
host?
No, Mongrel loads up the entire application environment. So a mongrel
process can only handle one application. You specify how many
processes per app in your config file.
Also, what’s a good way to calculate the needed number of mongrel
instances I’ll need? For example, in a mod_php server here there are
48 instances of Apache running simultaneously. If this was a rails
server with mongrel, would I need 48 instances of mongrel? Can this be
made dynamically (i.e., mongrel creates more instances as needed)?
There’s no way you need that many. Basically the only way to do this
is config and test. Start up two mongrel processes, hammer away at
your app, gather stats, and see if you need more. As I said in an
earlier email, I’ve got 3 processes handling 80k requests/day on slow
code, and it runs great.
No, Mongrel loads up the entire application environment. So a mongrel
process can only handle one application. You specify how many
processes per app in your config file.
Does that mean that if I have 10 applications, I’d need 10 separete
mongrel_clusters, each running a given (pre-configured) number of
mongrel instances?
Does that mean that if I have 10 applications, I’d need 10 separete
mongrel_clusters, each running a given (pre-configured) number of
mongrel instances?
Yes
Which is nice - you can run a different mongrel_cluster for each hosting
client, giving clean privilege separation by user account. A simpler
suexec, as it were.
One concern I have about proxying to backend processes is SSL
connections - given that mongrel doesn’t support SSL, your previously
SSL’d data is getting passed to your backend processes in plain text. A
malicious user on the same machine could sniff this proxied traffic as
it goes to your backend and do Bad Things. I still haven’t heard a
satisfactory solution to this one. . .
No, Mongrel loads up the entire application environment. So a mongrel
process can only handle one application. You specify how many
processes per app in your config file.
Does that mean that if I have 10 applications, I’d need 10 separete
mongrel_clusters, each running a given (pre-configured) number of
mongrel instances?
Which is nice - you can run a different mongrel_cluster for each hosting
client, giving clean privilege separation by user account. A simpler
suexec, as it were.
The problem I see with that is that if the number of accounts on the
server is large, there’ll be need for a large number of mongrel
instances, and if you consider that a good share of these accounts
won’t have high traffic, you’d have a lot of instances using server
resources but not serving anything most of the time.
I think that, in some situations, a single pool of mongrel instances
would be a better solution, although I believe it’s not currently
possible to use mongrel like that.
That is why you test for performance. Every app doesn’t NEED 10
instances of
Mongrel. Many are fine with 2 or 3. You need to do performance testing
and
determine your own needs. Throw out what you know about serving web
applications because it’s just going to get in the way… Rails doesn’t
work
like that. Some apps need only one instance of mongrel because they
rely on
page caching which Apache handles nicely. Some need 10 because they are
really heavy applications with long-running processes.
PlanetArgon (good host for Rails) manages to allow each user a port
range
where they can run their Mongrel instances. So it’s not a real problem
if
you have a lot of accounts on the machine.
One concern I have about proxying to backend processes is SSL
connections - given that mongrel doesn’t support SSL, your previously
SSL’d data is getting passed to your backend processes in plain text. A
malicious user on the same machine could sniff this proxied traffic as
it goes to your backend and do Bad Things. I still haven’t heard a
satisfactory solution to this one. . .
That’s a valid point. However you have to remember that those are somewhat
rare cases. Your backends should be firewalled off and well protected
from
the outside world. If you have a malicious user in that backend machine,
you’re not going to be protected just because you have encrypted the
traffic. He’ll have your logs, passwords, etc.
That is why you test for performance. Every app doesn’t NEED 10 instances of
Mongrel. Many are fine with 2 or 3. You need to do performance testing and
determine your own needs. Throw out what you know about serving web
applications because it’s just going to get in the way… Rails doesn’t work
like that. Some apps need only one instance of mongrel because they rely on
page caching which Apache handles nicely. Some need 10 because they are
really heavy applications with long-running processes.
But if you have 100 accounts that’s 100 mongrels at least, more likely
200 or 300. If running 300 mongrels at the same time works fine, then
excellent! I’m just trying to learn from other people’s experiences
doing shared hosting with mongrel.
But if you have 100 accounts that’s 100 mongrels at least, more likely
200 or 300. If running 300 mongrels at the same time works fine, then
excellent! I’m just trying to learn from other people’s experiences
doing shared hosting with mongrel.
May I ask what you’re actually doing? From your original post I
thought you were just planning on deploying an application…where is
this 100 accounts all running 2-3 mongrels figure coming from?
If you’re just concerned about a shared host being overloaded, it’d be
far more appropriate to ask current customers what their experiences
with a particular host is. You can even ask the host how many
accounts are on the server, what the average load is like, what policy
they have on resource abuse, etc.
Mongrel truly is the best way to deploy Rails apps right now. I’m not
sure what you’re looking for, but it looks like the wrong thing…
Perhaps you’re planning on starting your own Rails shared hosting? If
that’s the case, there’s no way around the fact that Rails takes up
more resources than shared PHP does, so you won’t be able to cram 1k
accounts onto a server like you could with PHP. Just the way it is.
May I ask what you’re actually doing? From your original post I
thought you were just planning on deploying an application…where is
this 100 accounts all running 2-3 mongrels figure coming from?
It’ll be a server for shared rails hosting. I’m just trying to find
out what are the current alternatives for such a setup, given the
restrictions I mentioned on the first post (have to use apache, user
data is in a noexec partition).
Of course, I know rails will use more resources than PHP, that’s
totally expected. One of the reasons that a shared server with lots of
PHP accounts works is the fact that a lot (most?) of the virtual hosts
have such a low usage that they have little impact on the server
performance, since apache doesn’t pre-allocate resources tied to
specific virtual hosts.
I’m not attacking mongrel or anything like that. I’m just trying to
understand how it works to decide if it’s the right solution for me.
Of course, I know rails will use more resources than PHP, that’s
totally expected. One of the reasons that a shared server with lots of
PHP accounts works is the fact that a lot (most?) of the virtual hosts
have such a low usage that they have little impact on the server
performance, since apache doesn’t pre-allocate resources tied to
specific virtual hosts.
I’m not attacking mongrel or anything like that. I’m just trying to
understand how it works to decide if it’s the right solution for me.
Resource wise mongrel and mod ruby will probably be about the same,
but only if you run a mod ruby enabled apache behind another apache
that serves your static content. Every apache process is going to
have the ruby interpreter loaded. Mod ruby might not even work in a
shared environment either. Can it run multiple rails applications in
a single apache process? Might want to check that out.
