eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
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.
Monitor and Measure Everything
No. 4: Monitor and measure everything
Monitor and measure everything and I do mean everything: servers, resource usage, behavior of applications, response times on pages-anything and everything relevant. As you are monitoring, collect as many metrics as you can. That way, if problems arise, you’re armed with information, performance trends and context. This is where monitoring tools designed to spot performance problems really come in handy.
Without monitoring and logging, you lack visibility into the system. If a problem does arise and you don’t have relevant metrics to fall back on, you are faced with investigating everything it could possibly be-sounds pretty inefficient, huh?
No. 5: Make your staging environment a faithful replica of your production environment
Many developers develop and test their applications locally and then jump the gun by deploying straight to production. They then face problems, because the actual production environment acts differently from their laptop.
The closer your staging and quality assurance environments are to your deployment environment, the better. The staging environment doesn’t have to be as big, but it should at least be running the same versions of all the software. Ideally, tests should also be run with a copy of the production data set to mimic the conditions of deployment. The big benefit here is catching errors during staging before the application is pushed to production; it will save you time, energy and stress later on.
Ruby on Rails gets you to your endpoint faster and gives you time to think about how you can scale your application. But it won’t do the job for you. By keeping these five points in mind, your application will scale while your management headaches shrink.
Ezra Zygmuntowicz is a co-founder and developer at Engine Yard. Ezra has been active in the Ruby community for over four years and has contributed to many open-source projects, including Rails, Merb, Rack and Rubinius. Ezra is also co-author of Deploying Rails Applications: A Step-by-Step Guide (published by The Pragmatic Programmers). He speaks at Ruby, Rails and cloud computing-related events throughout the United States. He can be reached at ez@engineyard.com.