Real world Rails: Caching in Rails

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

Read more at DevloperWorks

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s