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.

Its been a long time coming but we’ve finally got our new site design finished for Onomojo. We’ve also expanded our services to include graphics design, logo design, web design, and a whole slew of other graphics related services. That’s in addition to the services we already provided which were primarily programming, seo, and marketing related. Here’s a screenshot of the new design.

I’ve reached my limit of frustration with current keyword trackers. The technology is simple enough that it baffles my mind why so many keyword rank trackers are for profit. There doesn’t seem to be a single decent instance of an open source keyword tracker out there that I could find. I want something open and that can run in Linux of course but my searches have left me empty handed.

I’ve started designing my own keyword tracker as a result. I will release it under the GPL because I like to keep it real like that. It will be a Rails application and I will host a version for people to use free of charge (with some limitations so it doesn’t kill my servers). Basically, you can extend the app by creating a Rails plugin for it for different search engines. I will just write one for Google for starters. Hopefully I can get some community support to get more search engines working for it. I’ve got the database mostly planned out and will be starting the project in the next week or two. I will make an instance of Trac to help the collaboration and issue tracking.

Basically, I’ll be creating something that will have multiple users. A user can login and enter a new site or track an existing site. Each site has a set of keywords which the app tracks over time. I want graphs of the keyword activity over time and I want the ability to import keywords and export the rank history. If anyone is interested in helping me out on this project just comment on this post to let me know and I’ll set you up with a Trac account so we can get started.

I’ve found on numerous occasions that I needed to recursively remove all the .svn directories from a checked out copy of my code. I’ve always just googled it and found the command quickly that way since I don’t know how to do it off the top of my head. I consider myself pretty fluent in Unix systems but there are just some commands that I’ve never really dug into much. Here is what google turns up:

find . -name .svn -print0 | xargs -0 rm -rf

How does that really work? Well, we first have to understand how the first command works before the pipe:

find . -name .svn -print0

If you omit the ‘-print0′ it simply dumps all the .svn directories it finds recursively from the current directory. The ‘-print0′ works in conjunction with the ‘-0′ option inside the pipe. The ‘-print0′ basically doesn’t return a new line but rather formats the output in a way that you can process each element of the results using the ‘xargs’ command.

xargs -0 rm -rf

That command really won’t do much unless you pass it something, usually through the pipe. So, ‘xargs’ just takes the output from the find command and process each element of the results by passing it to the command specified. In this case it is ‘rm -rf’. So combined we have ‘find’ getting all the results and piping the whole thing to ‘xargs’ and ‘xargs’ passes each element of that set to a ‘rm -rf’ command. Its fairly simple when you break it down.

Anyone in their right mind who is running a mission critical database is already doing daily backups of the database. Its not often feasible to backup the entire database more than that. Without a proper plan, you’re stuck with a possible 24 hour data loss in the event the server dies just prior to its next backup. All transactions throughout the day are lost.

Luckily you can configure MySQL to store binary logs of all transactions that modify data in the database. These logs are typically going to be much smaller than your entire database so you can simply back them up more frequently than your entire database backup. When recovering from a system failure you would simply first restore from a nightly backup. Then restore from your binary log backups to ultimately reduce your data loss to whatever interval your binary log backups are set to.

To do all this you need to add the following lines to your my.cnf file:

log-bin = /var/log/mysql/.whatever
binlog-do-db=
expire_logs_days=2


I like to store 2 days of binary logs just in case something is screwed up I have 2 days worth of transactions I can potentially restore from. When restoring you need to be careful not to repeat transactions from prior to your nightly backup. So, if your nightly backup was exactly at midnight, you want to make sure you restore only the binary logs that occurred after midnight. Then you need to set a cron job to do the backup for something like every 5 minutes and you’re good to go.