These forums are locked and archived, but all topics have been migrated to the new forum. You can search for this topic on the new forum: Search for Support for mod_rails on the Horizon? on the new forum.
Web Hosting and Cloud Computing Control Panels
This was discussed a few weeks ago. mod_rails isn't suitable for a shared hosting environment (what the vast majority of our customers are using Virtualmin for), as it doesn't work with suexec.
But, the number of developers using Virtualmin in a non-shared environment has increased over time (partly because of the easy to manage Rails support)...so it's very likely we will do something with mod_rails in the future.
However, I'm curious what you find isn't "viable" about the current mongrel deployment method? This has been considered "best practice" in the Rails community for some time. mod_rails is an attempt to make deployment easier...but Virtualmin already makes mongrels and proxy_balance easy. ;-)
--
Check out the forum guidelines!
Joe,
Perhaps "viable" was a poor choice of words. From the research I've done, it seems as though serving up a Rails app with mod_rails would be better from a resource standpoint than having mongrel running as a daemon.
I'm pretty new to Rails development, so forgive me if my terminology is off. It just appears that mod_rails would be less resource intensive. I was not aware of the issue with mod_rails and suexec.
- dimpared
mod_rails may be more efficient, and that is a consideration...particularly in virtualized systems, which tend to be smaller (and not often shared).
But, in a high volume deployment, I suspect mongrel is still the better option--historically speaking, "mod_*" versions of languages perform roughly identically to mod_fcgid. They perform the same basic optimization, which is to keep the language binary loaded at all times so there is much lower startup cost. But, Mongrel can share more resources than individual Apache instances, and so it can likely be more efficient in a high load environment. I'm an expert in neither, but that's the understanding I have from reading the various docs on the topic.
If the various mod_ packages supported suexec, I'd be a happy chappy. Even in a non-shared environment, it's nice to be able to fully isolate different applications in security critical situations. But, for most folks using Rails, they're deploying just one app, so it's not really relevant.
--
Check out the forum guidelines!
Hi Joe.
I'm not sure what you're talking about. Passenger doesn't work with suexec, but it does support user switching, like suexec. Unlike suexec, this works automatically and is turned on by default, without any need for complicated configuration options. It has been <a href='http://www.modrails.com/documentation/Users%20guide.html#user_switching' target='_blank'>documented in our users guide</a> since the first release. There's even <a href='http://www.modrails.com/documentation/Security%20of%20user%20switching%2... target='_blank'>a document for developers and system administrators</a>, in which we explain the problem, existing solutions that we have investigated (including suexec) and the solution that we eventually came up with, for the people who are being skeptical.
<div class='quote'>This has been considered "best practice" in the Rails community for some time.</div>
Well, we're getting <a href='http://www.modrails.com/testimonials.html' target='_blank'>praise from DHH himself</a>. His words: <i>"This could definitely become very popular, very fast ;)"</i>.
We've received similar praise from other important people in the Rails community, such as Pratik Naik (Rails core developer) and Yukihiro Matsumoto (Ruby author). Dreamhost, one of the largest shared hosting companies in the world, is deploying Passenger as we speak. Media72, a United Kingdoms-based, is <a href='http://hosting.media72.co.uk/blog/2008/05/01/new-mod_rails-hosting-packa... target='_blank'>already offering shared hosting packages</a> based on Passenger. Ditto for <a href='http://www.hostingrails.com/mod_rails_hosting' target='_blank'>HostingRails.com</a>.
<div class='quote'>But, Mongrel can share more resources than individual Apache instances, and so it can likely be more efficient in a high load environment.</div>
I'm not sure where you get that information from. Mongrel instances do not share any resources, at all (except of course the program code of the Ruby interpreter itself, but that's only a tiny amount of the actual memory usage). Passenger on the other hand makes use of copy-on-write memory management technologies in modern operating systems. In combination with our yet-to-be-released "Ruby Enterprise Edition", Passenger can allow an average case memory reduction of <b>33%</b>, compared to Mongrel. More details will be available soon.
<div class='quote'>I'm not sure what you're talking about. Passenger doesn't work with suexec, but it does support user switching, like suexec.</div>
Holy crap, that's awesome! I searched for "mod_rails suexec" via Google to no avail, and searched your site for "suexec" with no result (but this was on the day mod_rails was announced, so maybe all of the docs weren't in place).
We will add Passenger to Virtualmin ASAP. It's not that we like herding a bunch of mongrels...it's just the only way RoR could be deployed with good performance.
<div class='quote'>I'm not sure where you get that information from.</div>
As I mentioned: I'm an expert in neither, but that's the understanding I have from reading the various docs on the topic.
So, apologies for being mislead by the various docs on the topic I read.
Thanks for chiming in, hongli. I'll be packaging up Passenger and ask Jamie to add support for it to Virtualmin.
--
Check out the forum guidelines!
I forgot to mention this in my last post: I'm from Phusion, and I'm one of the Passenger developers. :)
When I tried to edit my last post I got "Oops! You've hit a bug in the forum software. It'll be fixed soon.".