Railsmagazine60x60 Scaling Rails

by Gonçalo Silva

Issue: Vol 2, Issue 1 - All Stuff, No Fluff

published in June 2010

Goncalo silva

Gonçalo Silva is a soon-to-be software engineer from Portugal who always had a crush about performance. Being a freelance web developer for many years, he started using Ruby on Rails in 2007. He works for Tecla Colorida, creators of http://escolinhas.pt, where he began using RoR in 2009. Later that year, he engaged on a master's thesis entitled "Scaling Rails: a system-wide approach to performance optimization", mixing his passion about Rails and his obsession for performance.

He spends most of his time tweaking open source projects, from operating systems to graphical user interfaces. This hacking instinct surrounds his love for open source software, allowing him to make small contributions to many projects. You can find more about Gonςalo by following him on twitter (http://twitter.com/goncalossilva), visiting his website (http://goncalossilva.com) or taking a sneak peak at his Rails-oriented blog (http://snaprails.tumblr.com).

The term Web 2.0, born somewhere in 2001, is related to improving the first version of the Web. It aims at improving user experiences, by providing better usability and more dynamic content. Many web frameworks, including Ruby on Rails, were born as part of this huge web momentum that we still live in nowadays.

Most websites are built to provide great user experiences. Recent studies show that users won't wait longer than 8 seconds before leaving a slow or unresponsive website. This value keeps getting lower and lower as users become more demanding.

This is the introductory article in a short series related to Ruby on Rails Scalability and Performance Optimization. Application performance is influenced by every related component, besides the framework itself.

Website performance

Developers often oversee that web applications need to be fast and very responsive as part of a richer user experience. Having a highly efficient platform will generally allow lower expenses on hardware but also lower response times, making its users happier. In some cases this  need can be extreme – a high-demand platform strives for scalability as its users keep growing.

Ruby on Rails is widely known for being optimized for programmer productivity and happiness, but its scalability or performance are not generally favored. Many well-known platforms like Twitter or Scribd have put enormous efforts in improving these characteristics and sometimes faced a few issues while doing it – we all know the famous “fail whale”.

System resources

Few people have access to top-notch resources. Most need to deploy and maintain a Rails application on a shared host, limited VPS or even a dedicated server. High-end computers or server clusters are not easily accessible to the masses but every developer should to be able to provide great services with limited resources.

The answer to every scalability issue is not “just throw more hardware at it”.

Components involved

Most servers run Linux, while a few use FreeBSD. Every operating system has a different philosophy to almost everything – from the file system to networking I/O, and these details can impact all the other components.

Some applications use Ruby 1.8, while others are already riding Ruby 1.9. There are many Ruby interpreters, from MRI to YARV, including widely-known implementations like Ruby Enterprise Edition, JRuby or Rubinius. Each of these has its particular characteristics, offering distinct advantages and disadvantages.

Few applications are built or have been ported to Rails 3, which brings large performance improvements. Porting is an important step as Rails 3 provides reduced computing times and memory usage, when compared to its predecessor.

When it comes to web servers, the number of choices are tremendous. From the traditional combination of Apache and Mongrel, to the popular Passenger for Apache and Nginx, to newcomers like Thin and Unicorn, every application has an ideal setup and its web server architecture greatly impacts its performance and memory usage.

The database choices, ranging from popular relational databases like MySQL to more recent NoSQL projects like Cassandra or MongoDB also have associated advantages and disadvantages. This aspect gains a lot of weight, considering that the database can be a major performance bottleneck.

Let's not forget about the application itself: coding conventions could be followed to improve the application's performance, scalability and, most importantly, the code's quality.

Your system, your architecture. It's all about choice.

Final thoughts

Every aforementioned component will be covered in this series, making Rails' developers and system administrators aware of their advantages and disadvantages. Ruby on Rails' scalability on a modest system can be easily improved. Reducing response times and making users happy – another step towards greatness.