About this series
Rails has an unmistakable reputation among developers. Rails represents buzz and sizzle; extreme productivity, and controversy. Depending on who you ask, Rails is hyper productive or a toy, well marketed or over hyped. Like many newer technologies, Rails also has a reputation as unproven with limited scalability. Unlike the C and Java™ languages, Ruby is interpreted, with all of the inherent performance handicaps.
In reality, many of the largest sites on the Internet use interpreted languages. They use the same strategies that Ruby uses: clustered, shared-nothing architectures. And they cache. To get the best possible performance, most sites will need an effective caching strategy. Rails developers are beginning to follow suit.
A few scenarios
First, allow me to walk through a few pages of ChangingThePresent.org. I’ll show you a few places on the site where I’m likely to need a cache. Then, I’ll point out the choice we made for each, and the code, or the strategy, that we use to implement these pages. In particular, I’ll talk about what we do for all of the following:
* Full static pages
* Dynamic full pages that rarely change
* Dynamic page fragments
* Application data
