Does anyone have any recommendations when to use mod_rails vs a
mongrel/nginx stack? Is one better for low-ram situations or is there a
clear winner performance-wise regardless of hardware?
Thx,
Vince
Vince,
I’d suggest sticking with mongrel/nginx for now. We’ve had a number of
attempted mod_rails deployments. All of them have had various issues,
ranging between annoying and catastrophic. We currently only have one
customer using mod_rails, and we have had to restart apache and
manually kill off the rogue passenger processes every week or two just
to keep them up and running.
This is just what I’ve seen on our end, and there could very well be
people out there using it with no problems, but my suggestion is to
stick with mongrel/nginx for the time being until mod_rails has had a
bit more time in the wild to root out any issues.
On Sep 15, 7:11 pm, “Vince W.” [email protected]
I’d suggest sticking with mongrel/nginx for now. We’ve had a number of
attempted mod_rails deployments. All of them have had various issues,
ranging between annoying and catastrophic. We currently only have one
customer using mod_rails, and we have had to restart apache and
manually kill off the rogue passenger processes every week or two just
to keep them up and running.
On the flip side, we have a number of customers running mod_rails in
production (as well as our shared hosting platform that’s utilizing
mod_rails) that haven’t had any problems. We’ve been very happy with
the platform.
Our recommendation for new users is if they have two servers that are
load balanced, to try mod_rails on one and see how it goes. More often
than not, they end up switching all their servers to it.
–
Jesse P.
Blue Box Group, LLC
p. 800-613-4305 x 801
We’ve had good results with mod_rails in some instances.
Our main servers remain as Litespeed, but that too has its issues, as
sometimes Litespeed RailsRunner processes hang around even after you
shut it down, or restart it, leaving instances of old code.
Major downsides to a mongrel type environment is the care and feeding
of the mongrel pack itself, and that if you’re running many sites on
the same machine, it can be resource intensive with lots of mongrels
hanging around doing nothing. Litespeed and mod_rails will spawn
runners as required.
In one environment (primarily intranet) on ubuntu, we have had to
restart apache/mod_rails like once every 2 days. In another
environment with Centos, things have been rock solid. There are
certainly a few bugs, but if you have an environment where multiple
sites are on the same box, either Litespeed or mod_rails beats
mongrels hands down in terms of just maintenance, deployment, and,
surprisingly speed too.
- Ericson S.
CTO Funadvice
http://www.funadvice.com
We run a production CommunityEngine driven site using Passenger
without any problems so far. Before we’ve used mongrel behind an
Apache using mod_proxy_balancer. This combination was to expensive.
Now on the same machine running Passenger we have in average 6
spawners vs. 2 mongrel_cluster with 2 servers each.
just my 2 cents
Fritzek
poppster.com
I run a server at work that uses mod_rails quite successfully. It was
really easy to get started, and seems to be doing great. Something
particularly attractive about mod_rails was that we could easily host
any Sinatra app (we have a few of those running) and Merb apps too.
James H.
On Sep 15, 10:11 pm, “Vince W.” [email protected]
I have tested the same application on the same VPS with mod_rails and
mongrel behind nginx.
It is more easy to set mod_rails and you should use it for fast
deployment.
The spawn process was the killer.
The second thing that wasn’t running was javascript_include_tag
with :cache=>true.
Mongrel and nginx was not so difficult to set up, we already do this
so many times, and the performance was extraordinary as usual.
mod_rails will be the right choice soon but, still waiting.
On Mon, Sep 29, 2008 at 10:51 PM, dima [email protected] wrote:
The second thing that wasn’t running was javascript_include_tag
with :cache=>true.
What do you mean?
Just a followup to my earlier comments regarding the instabilities in
mod_rails. Having gotten a few systems up and running with an updated
version of Ruby (one of which is running Ruby Enterprise), we’re
seeing much better results overall. (e.g. No more out of control
passenger processes, etc)
Using a recent build of Ruby along with mod_rails is definitely a
viable solution for folks who prefer to use Apache. We’re still not
seeing any substantial performance differences to say that you
should use mod_rails instead of nginx+mongrel, but you can. 
If
you’re more comfortable with Apache, or if you’d like to run a PHP
site on the same machine, using mod_rails is definitely a good a
choice at this point.
Here is some description of situation that I was in.
The rails app is not mine and I had just to deploy it for the proof of
concept demonstration.
The mod_rails was my natural choice. The folder privileges are set as
they should be.
Since that is on a VPS I have noticed the long first hit response time
due the spawn process.
That was expected but it was a bit to long for me.
Then I noticed that there is no mod_deflate and I include it too and
it was a bit better but cold start up was still to long.
Than I noticed that javascript_include_tag can be changed by adding
the :chache=>true directive since it was in production environment.
At first it helps and app becomes more responsive.
Then the second time I have start the whole system again at first I
have got a 503 and on a second request everything is working OK.
This was repeatable on every first spawn hit.
For some reason I try to check to see what the all.js is looking and
noticed a strange message from a firebug that this file is missing.
Then I requested just the all.js from the browser and the same result
– 404.
Even to my biggest surprise no message in production log or apache
logs except ones for 404.
Since I was on a tight schedule the solution was: go with the known.
Just fire up a mongrel, witch was not present at the time of previous
test, and width plain vanilla setup.
Everything was working right of the box, the all.js was present and
response time on first hit was as expected.
I will try to make the same situation again ASAP to be able to go
little deeper in.
If I find some new light on the case I’ll post it.
The mod_rails is a good solution for fast deployment and it’s much
easer to educate people to use it.
Alex Malinovich wrote:
Just a followup to my earlier comments regarding the instabilities in
mod_rails. Having gotten a few systems up and running with an updated
version of Ruby (one of which is running Ruby Enterprise), we’re
seeing much better results overall. (e.g. No more out of control
passenger processes, etc)Using a recent build of Ruby along with mod_rails is definitely a
viable solution for folks who prefer to use Apache. We’re still not
seeing any substantial performance differences to say that you
should use mod_rails instead of nginx+mongrel, but you can.
you’re more comfortable with Apache, or if you’d like to run a PHP
site on the same machine, using mod_rails is definitely a good a
choice at this point.
Interesting. We’ve seen a number of people claiming that Phusion
Passenger doesn’t work very well (= crashing every few hours, processes
that get stuck, etc) even though we can’t reproduce their problems at
all. We haven’t considered the possibility that their Ruby interpreter
might be the problem.
Which Ruby version were you running before, and which version did you
upgrade to?
Most of the problems happened with 1.8.6p114, and most of them were
resolved with either 1.8.6p287 or Enterprise Ruby.
On Oct 6, 3:08 am, Hongli L. [email protected]