Enlightenments from RailsConf 2008
June 4, 2008
Some people want to go to RailsConf and learn about new features coming up in Rails 2.1 -- that's not me. If I wanted to learn what's new in Rails 2.1, I could read it online and save a trip to Portland. For me, it's about meeting like-minded developers who understanding how to use Rails to do better software development. Below are some personal highlights from the conference.
I enjoyed Joel Spolsky's keynote which had nothing to do with Rails. The theme was Building Great Software. In addition to learning how to build
great software by making users happy, I was happily informed that putting a picture of Angelina Jolie on a slide for 30 seconds boosts the presentation rating by 10%. I will definitely keep that in mind for future presentations.
DHH, the father of Rails, revealed nothing about new feature in Rails. A good quote from his talk:
You are tired and you keep working for another 8 hours, and you are going to spend the next 20 hours fixing it.
For me, scaling Rails is just like scaling any other web application. I am a big fan of memcached. I like to cache everything in memcached and put any slow processes into a queue. Since memcached is horizontally scalable and shared among all the Rails instances, it is a cheap and easy way to scale your application. Here are a few other good scaling techniques people mentioned in the talks:
- Write Mongrel handlers which handle the requests without going to Rails.
- Put Rails into EC2 so when you get stuck, it buys you time to tackle the problem without suffering from performance. Downside: you might get a big
bill from Amazon.
- Have good monitoring in place which helps you to analyze the issues.
- Put in "knobs" to tune your application performance.
- Able to throttle things dynamically.
In my opinion, scaling is not a problem for Rails in 99% of the cases. Don't think about it too much and do the simplest thing that could possibly work. After all, needing to scale is a good problem to have.
- JRuby: i18n, single thread, poor memory management -- all these problems go away with JRuby. Your organization is old-school and only want to deploy Java applications? Use Warbler to create a war file for your Rails app and hand the file over to your release engineers to deploy your "Java" app. Done!
- DataMapper: Does your application have high concurrency operations that ActiveRecord is blocking because it is not thread-safe?* Does your application have a hard time talking to a legacy database which does not obey the conventions? Does your application want to talk to multiple databases or even a data source that isn't a database? DataMapper to the rescue! It's a thread-safe, flexible ORM that can easily be extended to talk to any data source. Sounds pretty cool, don't you think?
- EventMachine: Want to implement a small custom service? EventMachine is another alternative to BackgroundDRB for handling background tasks and help scaling your application.
- Others: I heard there were some good sessions talking about Rubinius, MagLev, and other things that I missed. I wish I can go to all but too bad there is only one, non-threaded instance of me. ;-)
If you combine everything together, you can create an architecture with theoretically high-performance and high-concurrency as illustrated below.
One day, you may need a super-scalable architecture to keep up with the traffic. But before that, it's more important to focus on building a great software that makes people happy.
*Rails is not thread-safe so you'd probably want to use Merb instead of Rails.