Rails Application Scaling Tips

Written on 9:34:00 AM by S. Potter

This will be a howto on quickly enhancing performance, throughput or uptime of a Rails application:

  • Use memcached for sessions
  • Move static assets to separate lighttpd or httpd web server optimized for just static content
  • Use more efficient templating engine such as erubis
  • Use memcached for other high-frequency read AR models
  • Configure Rails to cache pages, actions and fragments where relevant
  • Use BackgrounDRB to delegate longer running tasks such as sending emails, etc. Note: This is out of date right now, I might recommend Cloud Crowd or other plugins at this point for background jobs or even using message oriented middleware (MOMs) like AMQP services like RabbitMQ.
  • If your application requires a large number of concurrent large file uploads (say you are building the next YouTube) you should consider utilizing Merb. Note: this is also out of date since I wrote it in May 2007.
At this point you just need to focus on the standard scaling concerns:
  • database server tweaking (including database caching)
  • removing unnecessary file system I/O
  • removing unnecessary or consolidating network I/O
  • Removing unnecessary computation or caching computational results where necessary
  • etc.

Update (2010-08-15)

The following tools/plugins can be used to optimize the how many and how much data is passed by the SQL queries generated by ActiveRecord:

  • Bullet - helps you optimize your SQL queries by notifying you when not eager loading or using counter caches.
  • Scrooge - SQL query optimizer which can reduce the amount of data getting sent from your database to your Rails application.
  • Rack-bug - reports stats about each request in development mode so you can see how many queries are being executed on each request (and a number of other useful request stats).

For identifying memory bloat or leaks in the applications the following might be useful (when we have a need for such tools):

  • Memorylogic - logging memory usage.
  • Oink - for easily finding actions that significantly increase VM heap size.
  • BleakHouse - used this before for finding memory leaks in a Rails 1.2.3 app a couple of years back. I believe it is working against Rails 2.3.4 apps now too.

Also nesting includes on eager loading in ActiveRecord used to have memory leak implications. I wrote about my experience in 2007 here: Twas the night before launch.


The memory leak from the Twas the night before launch blog post may have been fixed in subsequent releases of ActiveRecord since July 2007 when I encountered it, in the case of nesting includes for eager loading in all one query, but the morale of the story is never assume that just because you are eager loading all in one query there aren't going to be other implications.

If you enjoyed this post Subscribe to our feed

No Comment

Post a Comment