Webアプリケーションをキャッシュする方法は膨大にあり、複雑なことが多い。アプリケーションのインフラが増大するにつれて、Basic Railsのページキャッシュングは、退屈なものになりかねない。Rails 2.2は、httpヘッダーであるlast_modifiedとetagを使用し、条件付きGET(リンク)を導入した。RFC2616のインターネットスタンダー ドキャッシングのセクションに従いつつ、Ryan Tomayko氏はRack::Cache(リンク)を採用した。
Rack::Cache(リンク)はRack(リンク)ミドルウェアのピースであり、一連の基本的なストレージオプション(リンク)(ディスク、ヒープおよびmemcached)や キャッシュポリシーを調節するための構成システム(リンク)などの、たいていのRFC 2616のキャッシング機能(リンク)を実装する。すべてのRack可能なRubyのWebフレームワークと同等に機能し、Ruby 1.8.6および1.8.7でテストされる。
その設計の一部は、PythonキャッシュフレームワークであるDjango(リンク)に、インスパイアされている。
Rack::Cacheは、ゲートウェイプロキシ(Varnish(リンク)、Squid(リンク))として動作する。Rack::Cacheは、有効期限ベースのキャッシング、検証モデルおよびVaryヘッダーフィールドをサポートする。
Ryan King氏が述べるように(リンク)、アプリケーションがそれを本当に必要としているならば、真のゲートウェイプロキシにスムーズに移行することができる。
いったんアプリケーションが大きくなり、複雑になると、squidやvarnishのようなhttpリバースプロキシキャッシュを使用するのが道理にか なっているが、rails型のページキャッシングからHTTPキャッシングへ遷移することは重要なことである。あらゆる方法でデプロイメントおよびアプリ ケーションを変更しなければならない。面白くない。
Rack::Cacheを使えば、デプロイメントだけを変更すればよい。それを徐々におこなうこともできる。Rack::Cacheを使用して、ヒープで キャッシュし、その後filesystemに遷移し、最後にmemcacheに遷移する。拡張可能性の限度に到達する場合、アプリケーションの前で squidやvarnhishを追加すれば、Rack::Cacheを除去することができる。各ステップで、大きな変更が1つだけのデプロイメントは、1 つの操作でいくつか大きな変更をするよりもはるかに簡単にうまくいく。
Ryan氏のベンチマークを参考にすると面白いだろう。