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’ve been reading a lot of news lately about this Yahoo / Microsoft deal that fell through. Now the latest is that some big share holders are trying to force the deal to go through by replacing Yahoo’s board. It just goes to show how Wall Street misunderstands the situation. Stocks increased on the run up to the deal deadline. After it fell through, Yahoo stocks slipped. Anyone with half a brain would have picked up a few shares after the slip which is exactly what I did. Of course I’m not a 5% stake holder in the company but a few shares I do own and I felt like venting my frustration at the other vocal shareholders trying to force the deal with Microsoft.

Yahoo has long been in battle with Microsoft even from the early days with Hotmail. A deal with Microsoft would essentially devalue the Yahoo brand and have it lose respect among the geek community. Over the past year or two Yahoo has been growing its web business in the right direction. Its acquisitions of Flickr and Del.icio.us are just 2 examples off the top of my head. Those two names alone boost Yahoo’s appeal as a company which is why Microsoft is after them in the first place.

More importantly is their search technology. Despite Google’s dominance in search, Yahoo’s search engine has gotten extremely better over the past few years. Its results are typically much more accurate than Google’s in my opinion and they’ve been growing more and more appealing as an alternative to Google’s mythical magic search engine. Anyone who watches search engine rankings will tell you that Yahoo’s search results are much more consistent over time which makes it even more appealing. Not only that but SEO for Yahoo versus Google is more scientific and less voodoo. Its just another reason why Yahoo has been looking like its positioning itself more and more to become an extremely formidable online presence. Microsoft recognizes that and wants to low ball them before they secure their footing and get a steal on a buyout bid. The stockholders are on Microsoft’s side because they see a potential short term gain in stock value.

What they fail to see is that a Yahoo - Microsoft merger would essentially ruin any chances of a truly successful online presence for Yahoo and Microsoft. Microsoft has proven itself incapable of bringing anything worthwhile to the online arena even with past acquisitions of online businesses. Its ultimately a dooms day deal for Yahoo that’s being pushed by a few big stockholders who want some quick cash and have little interest in the long term success of Yahoo’s technology. I’m behind their technology and support them but selling out to Microsoft is likely going to sour the support Yahoo’s built up in recent years and ultimately fail as usual in the hands of Microsoft. Microsoft is a has been. Ask any kid who’s used a Mac before. They’re desperate and see the writing on the wall. They want to prolong their demise by purchasing promising web companies.

My guess is that Microsoft has wooed these stockholders privately in a lobbying type effort. Their thinking is that instead of raising their bid that they’ll woo a few big stockholders to replace Yahoo’s board and get their low ball deal for the company. Its typical Microsoft at its best. Either way, Yahoo’s stock is destined to go up whether they sell or don’t sell. No sale means they continue their forward progress and continue to build their momentum in a positive direction. I’ll likely keep my shares in that case. Sell and I’ll likely sell my shares shortly before the acquisition so I don’t end up with a loss at the end of the day. I’m no day trader but those are my thoughts as a web developer who’s seen these two companies have their better days.