timed_fragment_cache

Railsは重い！
これは事実。大規模なフレームワーク、高度な抽象化は重いもの。
キャッシュを活用しないとやってられません。

でも、キャッシュ使ってると思うのが、失効処理の複雑さ。
Sweeperを使うったって、モデルの変更で失効させないといけないところが増えてくると、混乱します・・・
しかもSweeper、STIじゃ使えないしぃー
routeの関係でちゃんと消えないってトラブルだって聞くし・・・

そこで、厳密にモデル変更で即変わらないといけないところ以外の失効は自動化しちゃいましょう。
「timed_fragment_cache plug-in」ってのがあるみたいです。IBM「現実の世界のRails」で使ってました。

使いかたは簡単で、

<%- cache 'キャッシュの名前' do -%>
  <%- @articles.each do |article| -%>
    <%=h article.subject %><br />
    <%=h article.content %>
  <%- end -%>
<%- end -%>

ってやってたのを、

<%- cache 'キャッシュ名', 10.minutes.from_now do -%>
  <%- @articles.each do |article| -%>
    <%=h article.subject %><br />
    <%=h article.content %>
  <%- end -%>
<%- end -%>

って風に、第2引数に失効時刻を指定するだけ。

また、フラグメントキャッシュが生成されているとき、コントローラでの処理を省略したい時には、

<%- cache 'キャッシュ名' do -%>
  <%- @articles.each do |article| -%>
    <%=h article.subject %><br />
    <%=h article.content %>
  <%- end -%>
<%- end -%>

unless read_fragment('キャッシュ名')
  # フラグメントキャッシュが存在しないのでDBにアクセス
  @articles = Article.find(:all)
end

って感じだったのを、

when_fragment_expired 'キャッシュ名', 10.minutes.from_now do
  # フラグメントキャッシュが存在しないか、期限切れなので削除した
  @articles = Article.find(:all)
end

とするだけ。

これだけで、生存時間10分のフラグメントキャッシュが使えちゃうようです。
更新が遅れてもそれほど気にならないところならどんどん使えそうです。
そうでないところも、生存時間を短くすれば使えると思います。
ってか使うぜ！