Getting started with CachedModels from Luca Guidi on Vimeo.

In the previous article I showed how to take the advantage of Javascript for page caching.

This cache strategy allows to generate static HTML and allow the web server to serve it, without waste a useless Rails request/response cycle. But, since the cached page is stateless we ask help to Javascript for make it a little bit dynamic.

Flash

All of you has probably noticed that flash object is an enemy of page caching. Let me show you why.
class SessionController Now suppose the application is in a blank state, when the user hits the dashboard_url, ActionPack will cache the page, including the flash status. This means it will be always rendered, even if the flash will be expired.

Rails offer a multi-level view caching based on: page, action and fragment.

Page Caching

For Rails cache a page means to generate the HTML code on the first visit, then allow front-end web server to send it statically.
This is the fastest way to serve pages, because Rails puts the cached page in the public folder, the web server intercept the request and doesn’t forward it to the application server, avoiding an useless Rails request cycle.
class HomeController

Since I began to work as professional developer I learned a lot of stuff, but, first of all I learned to be honest with customers and with the Community. I have to admit: CachedModels 0.0.2 was a huge mess.

It was a broken version, due to wrong mocks in test. I apologize for all the problems you could encountered using it. Since I discovered all the errors, I worked hard to restore all the lost functionalities. But it wasn’t enough for me, so I focused my attention on performances, reducing cache accesses: now benchmark test tooks 36.015132 fewer seconds than plain ActiveRecord!

CachedModels hit 0.0.2.

First of all, I transformed it to a Ruby gem, so you can use it outside Rails! Second, I dramatically enhanced performances, avoiding useless cache lookups and expirations. Take a look at the new benchmark stats: 1000 requests with a level of concurrency equal to 100, tooks 6 fewer seconds, if compared with standard ActiveRecord.

I strongly encourage you to upgrade to the newer version.