October 30, 2007

Posted by John

Tagged server and thoughts

Older: RubyConf and Miscellany

Newer: KYTCR Part 1: Backups

Keeping Your Tag Cloud Running: Intro

Ok. So I got an overwhelming response to my last post about some things I have learned managing an ok sized rails app. And by overwhelming I mean 14 comments. Ha. Anyway, that is a lot for this here blog so I’m betting I struck a key. I put together a basic outline and I’ll now present that and explain the title of this article. First the title.

Why the title?

It’s simple really, and kind of funny. I was watching an Adobe Flex web demo a few weeks back and the presenter opened things up for questions at the end. One of the questions was: ‘Can ColdFusion make tag clouds as easily as Rails?’ Granted that could have been a neophyte, or a jokester but either way it cracked me up. I mean all Rails does is tag clouds, right? So the question spinning through everyone’s minds is “How can I keep my tag cloud up” and ready for consumption by the web 2.0 beta croud, especially when you get techcrunch’d. Anyway, enough about the title, let’s get to the meat.

A little background

This is not a “how to scale twitter article” as there are plenty of those already. Most likely if you need to scale like that you shouldn’t be reading blog posts but should be hiring a team with previous experience. This is, however, an “I know rails, have an app or two in production and want to do whatever I can in my limited time to make sure things run smoothly” article. I keep a few rails applications running and for the most part they lay dormant. The one app that does handle some load is a multi-site content management system. It is currently serving over 400,000 page views a month (according to Google Analytics). It runs on one 512MB web/app server (with 4 instances of mongrel) and one 512MB database server (which also is the db server for a few other apps). Not huge but it’s growing quickly (a month ago it was only around 100,000 page views). That is what I’m dealing with. You could be dealing with more or less but regardless the stuff I’ll be posting I hope will be helpful.

The Outline of this series

So here are my thoughts and what I have minor knowledge about. I want this to be a legitimate resource for Rails’ers so if you have other ideas, comment and I’ll try to fit them in where possible. Also, if you are an expert about any of the topics that I mention below, let me know and maybe you can give the post a once over before I release it to the masses. In no way do I consider myself an expert or heck, even an intermediate on any of these topics, but I got them all working (cheers to me) and figured there are others in the same boat. I’m probably not the best person to write on these topics but those people have everything under control and probably think it is too easy to deserve a blog post, not realizing that the rest of us are all clamoring for it. These are in sequential order and are not currently written (just notes jotted).

  1. Backups. The first and most important thing once your app is up and running is making sure you can recover from problems.
  2. Short Term Problem Analysis and Resolution. Ok, something just went wrong. What? This post will provide a few tips for how to troubleshoot quickly and, most important, calmly.
  3. Automating Problem Resolution. Monit, everyone’s favorite faithful employee.
  4. Resource Reporting. Munin. Who doesn’t love an awkwardly ugly graph that shows memory consumption and such?
  5. At this point you have backups, know how to solve easy glitches, have automation for nighttime problems and reporting so you can figure out why monit is emailing like a desperate ho. What you need now is simple fixes and some optimizations. Ever notice your 500MB log file? Yeah, it’s time for log rotation and analyzation.
  6. Hmm. Things seem to be running smooth but now we are getting a lot of data in our app and it is beginning to dog. Indexes. Yeah, heard of them before. It’s time to turn on slow query logging and check the output every now and then, analyze (word of the day) the output and add some indexes (that you should have added at the beginning). Oh, and get some idea if they actually helped.
  7. Things are going good. Can we squeak a bit more out of our current setup? Some thoughts on alternate setups, multiple databases and caching.

Did I miss anything? Are you an expert on any of these? Let me know before I hit the Mephisto admin hard.


  1. Ned Baldessin Ned Baldessin

    Oct 31, 2007

    You should maybe start off by describing your favorite Rails stack (NginX or Apache?, etc), or any specific deployment tricks (user uploaded attachments stored on an asset server that need to be symlinked, etc) that you use.

    Common reasons why mongrels grow over-weight or die would also be great.

    Looking forward to reading you!

  2. Hi,

    I run a website called Muziboo.com and since I have moved from shared hosting to VPS, I have been using rubyworks and I must say it has really simplified my life with monit, runsv and related stuff. All the processes are now monitored and its so much more peaceful … previously one or the other process used to die out …

    May be you can talk about rubyworks in your series

    Thanks for this informative blog

    Prateek Dayal

  3. Hi, great posts so far, and the series seem like it’s going to be great. Congratulations, can’t wait to read the rest os the posts! Cheers.

Sorry, comments are closed for this article to ease the burden of pruning spam.


Authored by John Nunemaker (Noo-neh-maker), a programmer who has fallen deeply in love with Ruby. Learn More.


Release your software more often with fewer problems.
Flip your features.