Why not passenger / mod_rails?

By nahum | July 22, 2008

While I was holidaying over the weekend I received an interesting question via email, something along the lines of:

Can you give me a quick overview on what the trouble was running passeneger/enterprise ruby over multiple servers?  I’m half way through setting up our infrastructure with 1 load balancer passing on to 2 web servers…  running passenger/enterprise ruby.

The short answer is that there isn’t any problem - if you’re running Apache on each of your application servers.  I just don’t.

After an exchange of emails I learned that they are using the infrastructure provided for the contract being worked on, which isn’t necessarily their preferred choice.

The reason I haven’t followed the above paradigm is that Apache (or any hardened webserver) can handle several orders of magnitude more requests a second than what your average Ruby on Rails application can on the same hardware.  Say one Apache to one hundred mongrels, without being very scientific about it.  So why hamstring Apache to the lowest common dominator?  Given each instance of Apache has a minimum footprint, it’s a waste of resource.  Yes Apache also handles static files from disk that your app will never see, that still doesn’t change the equation much though.

Think of it this way, database servers get their own box early on, same concept.  Separate out the slowest beast into it’s own replicable box and just scale out from there as needed.  App servers should just have your application on them.  If you have more traffic than one Apache can handle, then you’ll obviously want to load balance to multiple web servers.

I’ve been stuck with a similar infrastructure hurdle before, in my case it was a hardware load balancer which the provider had setup stupidly.  It took them 4 days and two reboots to get it as I wanted it.  Extremely frustrating, especially as the reboots caused site downtime which I like to keep to a minimum.

For this project my intention is to performance test the updated configuration after each change and roll back when there isn’t a benefit.  I’m not going to have a hardware load balancer so I can’t really replicate the above, but I could pretend with three servers…

Anyway, I’m back online from relaxing over the weekend and sorting out what version and edition of ruby I’ll be using for my starting point.  After that I need to finish setting up the server for delivering a Ruby on Rails application and then actually create an application for deployment.  I’m open to suggestions.

[del.icio.us] [Digg] [dzone] [Fark] [Google] [LinkedIn] [Reddit] [Shoutwire] [Slashdot] [Sphinn] [StumbleUpon] [Technorati] [Twitter] More »

Related posts:

  1. The Plan. As I eluded to yesterday I’m going down the Ubuntu...

This entry was posted in Performance Project and tagged , , , , . Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.

2 Comments

  1. Mukund
    Posted July 22, 2008 at 10:22 pm | Permalink

    Use Ruby 1.8.6 with the last stable patch with Rails 2.1. I face render issues on my partials with Ruby 1.8.7 and Rails 2.1. The new version of Ruby is snappier though.

  2. nahum
    Posted July 23, 2008 at 10:42 am | Permalink

    I’d read that Rails 2.1 with Ruby 1.8.7 was snappier, but nothing much about view issues. I’ve done a bit of a google and not found anything, what sort of problems are you experiencing?
    I’m not looking at migrating an existing app for this project so likely won’t face similar type of issues I’m guessing.

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*

  •  

  • About Nahum Wild

    I'm a High Performance Website Consultant specialising in Ruby on Rails deployments. In this blog I cover common problems I've seen and provide insight on optimisation techniques.

  • Recommend Me

    Follow me on Twitter