Section 12.0. Introduction

12.0. Introduction

Discussing web application performance is complicated. There are many different aspects to performance, not the least of which is the user's perception: does the end user think the application is slow or fast? If she thinks it's fast, she doesn't care (though you may) that your servers are being pounded to death. On the other hand, a user with a slow Internet connection is likely to perceive your application as slow, even if your servers are running nicely. Of course, you don't have any control over the user's Internet connection or, for that matter, over her perceptions. Nevertheless, you usually want to make sure your application is as responsive as the most popular sites on the Internet that have a similar amount of content. Of course this is a very general goal and has more to do with what users are likely to expect than what your application may have to go through to generate its content.

For example, you may have an application that does some very complex reporting against a large set of data. Dynamically generating these reports may take a significant amount of time. Your users, on the other hand, expect that you should have solved this problem somehow and would like to see most pages returned in about the same time as it takes to render static HTML.

Think for a moment about the fastest web application you could write. It may be a CGI program written in C. In this case, the performance bottleneck would likely not be the application itself but perhaps a network interface or connection. Of course, the real performance problem with this is that writing a web application in C would be difficult to scale and maintain. Luckily, we're well beyond that and have wonderful frameworks such as Rails that abstract many of the complexities of such low-level solutions.

You use Rails because it makes developing web applications easier and faster. But how does this choice affect the performance your users will experience? You often pay the price for such high-level development in overall application performance. This is especially true of interpreted dynamic languages.

Rails addresses the performance issue in a number of ways. The first is the concept of environments. When you are developing your Rails application, you specify that Rails should run in development mode. This way, the entire Rails environment is reloaded with every request, letting you see changes you make in your application immediately. When you deploy your application, your situation changes. You now would rather see faster response times and less reloading of classes and libraries that are no longer changing between requests. This is what production mode is for. When an application is started in production mode, the entire Rails environment is loaded once. You'll see a drastic performance boost over development mode.

Let's get back to the expectation: users don't see the behind-the-scenes processing and think everything should be as fast as static HTML. This may sound pretty demanding. But if you think about it, a nontechnical user has no way of knowing what elements of a page are dynamic and which aren't. He will notice performance bottlenecks, and it may cost you valuable traffic if he decides your content isn't worth the wait.

Rails has a solution for this problem as well. Rails can cache the contents of dynamic pages, reusing pages that have already been generated when possible. When a user requests a dynamic page, the results are saved in a cache. Subsequent requests for the same content are served the static HTML with the assumption that there's no need to regenerate it dynamically. After some period of time or perhaps after an action that could change the dynamic content (such as an update to the database), the cached content is expired or deleted, and a new version of the cache is created.

Rails comes with three different ways to cache content. This chapter introduces you to each. I'll also introduce you to some tools for measuring performance. After all, the only way you can confirm that you are improving performance is by measurement.

Ultimately, your performance needs depend on a number of factors. There are many things you can do to improve performance with hardware or even by using more sophisticated deployment configurations. This chapter sticks (mostly) to solutions in the Rails framework itself.

Of course, measuring performance is ultimately about statistical analysis, and statistics is a deceptively complex subject. It's really easy to gloss over important details, so it's necessary to get your facts straight and get accurate measurements. It's important to know what you're measuring, and what it means. Zed Shaw has written an indispensable rant on the subject at http://www.zedshaw.com/rants/programmer_stats.html.