How to Scale Your Ruby Applications

Rails makes everything so simple for developers that it's easy to get trapped into thinking it will solve every problem, making it easy to stop paying attention to what goes on behind the scenes. Rather than relying on Rails as a cure-all, developers need to focus on scalability from the start. 

The truth is that Rails will only take you 80 percent of the way. To go that last 20 percent to a truly scalable application, here are five things to consider:

No. 1: Pay attention to your database

Database queries, especially in high numbers, are big performance bottlenecks. To get comments on a blog, for example, ActiveRecord may issue one query per comment if you aren't careful. On a popular blog that gets hundreds of comments, this means a few hundred SQL queries per page, which can be slow and inefficient.

This is known as the "n+1 query problem" and you want to avoid it. Make sure to use the proper "#include" statements in order to fetch these related objects in one query. Also, make sure not to take this too far and pull in thousands of objects at once. It is all about finding balance.
 
Rails eliminates a lot of the database grunt work but not all of it. Rails insulates programmers from SQL, but as the site grows and the application needs to scale, you will want to hand-optimize the database. To do this, you need to know what is happening there. Always tail your logs in development mode and watch to make sure SQL queries get dumped to your logs. That way, you know when the database is running too many queries and when to step in to make the process more efficient.
 
No. 2: Divorce long-running queries

No surprise: you want your application to run fast for its users. That said, users don't care what goes on behind the scenes. As such, anything that doesn't need to have results returned immediately to the client should be pushed to the background.

If a user makes a request to resize profile images, encode a video or do a roll-up report—things that may take time—there's no need for them to wait while a Web request is made. Instead, take the request, queue up the work to be done in the background, return status updates and have the page refresh itself when the job is done.
 
Rails typically serves one request at a time, and that's a detriment if there are long-running queries that block other incoming requests. Do the minimal amount of work possible during a Web request, and set up a queuing mechanism for the rest so your database isn't overloaded. This makes the application fast and keeps the front-end Web servers open.

A similar point: a lot of Rails applications deal with file uploads and user-generated assets. A lot of these applications store that data on Amazon S3. Trying to upload a video to an application while simultaneously processing images or uploading the video to Amazon S3, ties up the front-end Web servers. This means slow going for the user. Twenty Web servers can handle a lot of traffic, but twenty users uploading simultaneously with multiple requests means that others might get their requests rejected or timed out.
 
The bottom line: for efficiency's sake, never do image processing or upload files to another server during the request process. Instead, accept the upload, return success to client, and farm the rest of the heavy lifting for the background processing jobs to other servers.

No. 3: Use caching techniques to keep the load off your application servers and databases

Any time you can cache a computation or database query, even if it is only for a short time, you increase the scalability of your whole system. You can drastically keep the load down on your database servers by liberal doses of memcached. Memcached works by letting you store queries or computed objects in a memory storage that is distributed out across all of your application servers.

The general pattern is that when you fetch or compute an object, you store it in memcached. Then the next time you need said object, you first check memcached and, only if it doesn't exist there, you then fall back to the database or recompute the object and store it back in the cache.
 
A good developer needs to be aware of all the various caching features of the HTTP protocol on which all Web applications are built. By using these caching features (that can help you scale by not needing to repeatedly query or compute objects when serving them from cache), you can seriously cut down on the load of your whole stack.