Shanti’s Dispatches

One of the killer features of Ruby on Rails is its caching abilities, specifically fragment caching.

Rails fragment caching allows you to cache any piece of html or RoR-generated JavaScript.

Things like generating Tag Clouds are ideal for fragment caching — they generate a lot of SQL queries and you don’t need them to change that often.

RoR also offers page and action caching, but I haven’t found these to be as useful.

If you’re working with RoR on apps where you need to display different page elements depending on whether or not a user is logged in, then page/action caching does not help you so much. (though there some plugins to help you get around this problem)

At Sprout, we just deployed Mailroom 2.0. We’ve made a ton of improvements, but as part of that each Show Conversation request (made via Ajax, and cached on the client-side) was producing a ton of queries on the backend.

We’re doing a lot of stuff in that action — collecting messages and notes for the Conversation, checking hotlists, etc.

And it’s also the most-used system call in the application. The whole point of Mailroom is that you want to spend less time as a team managing your email, while still keeping that small company, good support vibe with your customers and clients.

That means the Show Conversation method needs to be fast. Blazing fast, hopefully. (which, under some scenarios, especially for power users, it hasn’t been 100% of the time — not that it can ever be 100%, but 95%+ would be nice =)

Fragment Cache Results

By implementing rails’ fragment caching for that action, I’ve got that action down to 3 SQL queries (and change):

Org Load
Member Load
Conversation Load
(there will be a few more under certain circumstances, i.e. of there is a note applied to the conversation)

When watching the rails log, this is then what I see next:

Fragment read: .00078

YEAH buddy!

.00078 seconds = 1,282 requests per second without breaking a sweat!

Of course, the real bottleneck, once this is implemented, gets moved up the chain, to the Org/Member/Conv loads. The only way to reduce those is to use something like memcached or to tweak Postgresql.

If you’re a Mailroom user, stay tuned in the next few days as hopefully some of these performance improvements will hit the streets!

You can bookmark this, digg this or check the cosmos