ADS specializes in using Ruby on Rails to build advanced, scalable, database-backed web sites for organizations of all sizes. Find out more at our website.

I couldn’t avoid going to the “Really Scaling Rails” presentation by Britt Selvitelle from Twitter, after all of the hubbub that surrounded their scalability issues. I was glad to hear that we address scaling along the same lines that they do. Here’s the low down…

Generally speaking, a Rails application deployment looks like this: Internet -> Apache2.2/mod_proxy_balancer -> mongrel_cluster -> MySQL. For smaller sites, Apache, Mongrel and MySQL are on a single box or VPS. Depending on the environment, memcache servers can also be sprinkled in between Apache and Mongrel servers, taking load off of the Mongrel servers and the backend database. Bottlenecks begin on the outside (or the Internet side) and move inwards. So, let’s see some solutions:

1. Apache: more front-ends + hardware load balancers
2. Mongrels: add more mongrel servers (with lots of memory) and configure Apache to only send one request to a single Mongrel at a time (i.e. one request per Mongrel)
3. MySQL: clustered database servers and memcache servers - try to keep out of the database as much as possible

Britt simplified the challenge to this: you either spend too much time in the application or you spend too much time in the database. Once you start tracking performance metrics in the app, can view lots of great and colorful charts, and are ready to move fast and scale quickly, address the issues.

Spending too much time in the application? Abstract long running processes using daemons - send em to the background. Also, make use of a queue. At Twitter, they use a pure Ruby distributed queuing system that can run nine or more daemons for a worker process.

Spending too much time in the database? Start by adding indexes to everything that you query on and avoid complex joins. Next, cache as if your life depended on it. Page caching in Rails is super simple, and other techniques such as action and fragment caching can speed things up as well. Once you’ve exhausted those, serialize, denormalize, and cheat (in a good way of course). Other miscellaneous tidbits that Britt left us with are:

• It’s OK to use Monit to kill processes if they get too big.
• Ensure that you can deploy frequently - enhance and deploy.
• Ensure that you can roll back easily - for those “oops” moments.
• Scale where it matters - where do your users spend most of their time?
• Some code is ugly. That’s OK.
• Ensure that your users can easily give you feedback.
• Use the community.
• Make an API - scale your developer base
• Twitter runs on edge Rails using Piston - weren’t we told NOT to do that?
• Put gems in Vendor - tweek em and keep em

The second presentation was Evan Phoenix from EngineYard talking about Rubinius. The purpose of Rubinius is to develop a better Ruby that will result in a better Rails. The project strives to address many of the pain points of the current Ruby interpreter. Per Eva, current pain points include:

• Memory usage - the Ruby garbage collector uses a lot
• Packaging and deployment
• Performance - people say Ruby is slow…
• Error reporting - back traces are illegible, even for developers
• Profiling - running it on a production server is crippling

Rubinius addresses these (respectively) by:

• Fork all you want, it won’t use more memory
• .war-like packages (.rba), pre-compiled code, meta data about a project (RDoc), and assets
• Inline caching, pre-compiled code, and JIT (eventually)
• Back traces are produced in Ruby code, are super easy to read, and even get their own extendable class
• A sampling profiler will always be available with little to no impact on performance

Rubinius is a very exciting project that everyone will be watching.

Next up are three keynotes - busy day.

Random Posts

• Sun Microsystems goes platinum and sponsors acts_as_conference
• ADS Partner FiveRuns Secures Funding and Announces ADS Partnership
• Happy birthday Ruby on Rails