FiveRuns Blog

We are excited about the release of mod_rails for Apache. Its innovative approach brings another promising Rails deployment option to the community. The Phusion team behind it has taken an open approach to developing and educating the community. This first release not only looks solid and well tested, it is also well documented.

After using mod_rails in a test environment for a couple of days, I see two typical usage scenarios:

1. As a Mongrel replacement on dedicated servers: If you run a Rails application on a dedicated server or virtual slice with a pack of Mongrels, you can simplify your deployment and remove an indirection. This especially applies if you already use Apache with mod_proxy_balancer. Instead of juggling all Mongrels and their respective ports, you can configure your environment exclusively through Apache’s httpd.conf file. Need more Rails instances to handle the load? Just increase RailsMaxPoolSize and restart Apache. Done.
2. As a new infrastructure for shared hosting: If you are a shared hosting provider that wants to offer reliable Rails application hosting, you now have a real option with mod_rails. FCGI never reliably worked in shared environments for Rails hosting. That situation inspired the development of mod_rails in the first place.

Rails Instrumentation

So, how does mod_rails work in conjunction with our Rails instrumentation? The short answer is: “It just works.” Since our instrumentation is written in Ruby, it is independent of the actual Rails container. Whether it’s Mongrel or mod_rails doesn’t matter.

The long answer has to distinguish between the two usage scenarios above. If you have a dedicated system, like in the first scenario, you can just switch from Mongrel to mod_rails and the FiveRuns instrumentation continues to run. We have one suggested configuration adjustment (see below) but that is optional.

Technically, our instrumentation still works in shared hosting environments, as described in the second scenario, but our current client architecture has not yet been enabled for these setups. The FiveRuns client not only collects Rails data but also other metrics from the operating system, web servers and databases. As a system service it initially needs root privileges for installation to become a system service (during runtime it operates with lowered privileges). However, in shared hosting environments users typically cannot install system services and execute long running processes. We plan to address this in the future.

Suggested mod_rails configuration adjustments

As a Mongrel user, I’m used to long running Rails processes. For example, in my test environment I run four Mongrel instances. I typically start those four processes up and then they continue running, under optimal conditions, until I deploy an application update or have to conduct general system maintenance.

Unlike Mongrel, mod_rails handles Rails instance creation and destruction much more dynamically. With its default settings you can observe mod_rails spawning and destroying Rails process instances within minutes. To me, this approach allows to dynamically allocate server resources in a memory efficient way. This seems especially important to shared hosting environments but not so much to dedicated server environments.

That being said, if you are moving from Mongrel to mod_rails and use FiveRuns Rails instrumentation, you might want to change the following mod_rails default option:

  RailsPoolIdleTime 120  

This parameter describes after how many idle seconds mod_rails will shut down a Rails instance. The default is 120 seconds. We recommend increasing this option to at least 600 seconds to streamline operations with the FiveRuns client. If you desire more Mongrel-like behavior in your dedicated environment consider increasing this option up to 3600 seconds or more.

Another default configuration parameter you will want to adjust is the following:

  RailsMaxPoolSize 20

It defines the maximum number of Rails instances mod_rails will create. In my test environment I typically use four. However, this number will be different for any environment. When moving from Mongrel to mod_rails you should initially use the same number as in your Mongrel environment. Please also note that RailsMaxPoolSize is a global configuration option. If you host multiple, distinct Rails applications with Apache this maximum will apply to all Rails instances across all applications.

Who is switching?

For us as a Rails management provider the interesting question is who will switch to mod_rails in their production environments? Please leave us a comment why you would switch to mod_rails or why you wouldn’t leave Mongrel.