I build a lot of Rails apps on a regular basis and each one I add to my server takes another bite out of my limited resources. The way I’ve traditionally setup a new Rails app was using a Mongrel cluster. I found it to be a lot more reliable and faster than the fcgi approach people use to use (and some still do). The downside to setting up a few dozen Rails apps on your server with each running a Mongrel cluster is that it eats up all your memory. One of my sites is starting to get a lot more traffic than it has been in the past and its putting additional strain on the server. As a result I decided to find an alternative to Mongrel. I’ve tried searching for alternatives in the past but everything sent me back to Mongrel. Until today of course when I came across Jamie Flournoy’s blog about mod_rails.

Excited for an alternative to raising a pack of resource hungry mongrels on my server I installed the gem and tried it out. It was exactly what I was looking for as far as ease of use straight away. All I needed to do was stop a mongrel cluster and simplify its virtual host directive in Apache to leave out the mod_proxy_rewrite and the other wonky rewrite rules. The first app I tested went smoothly but suddenly the server started misbehaving. Resources were being eaten and it wasn’t clear what was doing it because the app I was testing with is behind an Apache password and I’m the only user. I ended up having to turn off the mod_rails to get my system back in control. The problem turned out to be that by default mod_rails tries to test if your virtual host directory is a rails app or not. I have a few apps that I tossed in an instance of Wordpress into a blog directory inside my rails app directory. I found it convenient to toss them all into the same directory since its all the same website. As a result mod_rails was doing a ../ check to see if the blog directory was a rails app which it decided it was. That’s where the craziness came in because its a php application. Anyway, the quick solution was to move the blog directory out of the Rails app directory.

Other than that my memory usage is way down. I’ve migrated all my low traffic sites to mod_rails and I’m happy with how they’re performing. There is a little delay on the initial load of the app but subsequent calls are quick because its already loaded. I can wait an extra 2-5 seconds for my low traffic apps to load in exchange for hundreds of extra megs of free memory.

I haven’t moved over my higher traffic money making sites yet and I’m not entirely sure I will until I’ve tested mod_rails a bit more. I’m extremely happy with the results thus far though.

Rails page caching is pretty simple to get working usually. If you’re new to caching in Rails, there’s plenty of good tutorials out there to get you up and running in no time like this one from Rails Envy. Rails is a resource hog and on my servers I’ve got about two dozen apps running. Combined they use up most of my memory and on peek hours can push the server to the brink of disaster so caching is extremely important to keeping things under control. The last thing I feel like doing is having to offload some apps to another server. I’ve used fragment and action caching with great success but wanted to use page caching on a new app I am building. The problem I have been having was that the pages were being cached properly but Apache wasn’t serving them up. I tried a whole slew of different tweaks to my Apache configuration before finally finding the problem. I found the problem by including the following in my Apache configuration:

Using that debug information I was able to toy with the rewrite settings that were suggested by the many tutorials out there and find the problem. Most Rails page caching posts I found that used Apache and mongrel_cluster had a suggested rewrite configuration like this:

Now, this may be specific to my Apache configuration but what I found was that the rules weren’t rewriting to the correct urls. They were missing / and ending up relative. The way I fixed it was pretty trivial but took me some time to discover so I figured I post it. The solution ended up being like this:

I added some preceding /’s and removed the / after cache on the second rule since the $1 got translated with the /. This modified configuration got my page caching working properly.

I have a site that used non-english characters in the url. They were basically characters in Spanish for the names of things. Some had little accent marks on them and such. Anyway, everything worked fine in my browser using those characters in the url. My browser sees a link with the strange character and it escapes it to something like %3d. Great. The problem though, is that if I change my default character encoding to say Traditional Chinese that same character gets escaped into something completely different like %8f. That’s no good because when they try to visit that url it doesn’t always go to the same page. Why? I’m not entirely sure but I suspect its Apache or Rails translating that url using a certain character encoding.

Logic would tell you that I should just put the character encoding in the html headers right? Yes, that works in theory. Everything works in theory though. In practice, not every browser or spider actually listens to that. I mentioned spiders because some spiders will automatically assume a particular character encoding and do the same thing as a browser with the default character encoding set. What to do? What to do?

My solution was to just get rid of all non english characters. No one is accidentally escaping an ‘a’ to %ef. So far the solution is working out fine. I don’t entirely like the urls now but its better than having characters being escaped improperly by browsers and spiders.

I’ve just started using Mongrel instead of fastcgi for my Rails apps. Its only been a few days but I’m already loving the difference. Its so much faster than before. It wasn’t hard setting up either. Now Apache just proxies requests to Mongrel. I used this article titled Using Mongrel Cluster to set most of it up. I added a few minor customizations for my situation but nothing you can’t figure out from reading the article.