symfony 1.4 CacheHelper(cache関数) のその後

前回のまとめ

symfony 1.4のCacheHelperには余分なキャッシュを保存してしまう問題がある(多分)。sfViewCacheManagerのソースを見た感じでは、module名とaction名のみを基準にキャッシュ管理をしており、独自の内部URI(default/indexのような）をもたないcacheは制御が行えず、action cacheも同時に保存してしまうような仕様になっている。

対策

結局別にCacheHelperを作成する事で対応した。元々symfony 1.0の時からCacheHelperでは対応できない機能があったので、別途CacheHelperを作成して対応していた。

ソース github ライセンスはMIT

追加した機能は

1. 前回のブログで書いた余分なキャッシュを保存しないようにした。
2. 別途引数にinternalURIを追加して、複数のページで同一のキャッシュを使用できるようにした。
3. すでにキャッシュ済みか調べるための関数の追加した。

使い方

• cache関数の代わりにhr_cache関数を使用する。
• cache_save関数の代わりにhr_cache_save関数を使用する。
• hr_is_cached()関数はactionですでにキャッシュ中か調べて余分な処理を行わないようにするようなときに使用する。hr_is_cachedを実行した際の結果はstatic変数に保存され、その後hr_cacheが使用されたときと結果が同じになるよう保証する。(実行されるタイミングが異なるため、lifetimeが切れて結果が異なる場合があるため)
• 第三引数のinternaURIは例えば、URIが値を取る場合、’default/index?a=123’と’default/index?a=abc’では別のキャッシュが保存されるが、internalURIに’default/index’と指定することで共通のキャッシュが使用される。

効果

• ディスク領域の節約になる。
• internalURIを適切に設定するとキャッシュヒット率が上がり各種負荷が下がる。

本来であれば、componentを使えば良いが、componentを使うとtemplateファイルが分離され、設定も多少煩雑になるため、自分の場合どちらかというとCacheHelperを好んで使っている場合が多い。

ただ、殆どの場合通常のCacheHelperで問題はないと思う。効果があるのはページ数が数万～数十万単位あるサイトで、キャッシュ書き込みによりディスク負荷があがり、キャッシュファイルの増大によって(Linux等のOSの)ページキャッシュが圧迫されパフォーマンスが急激に低下するような場合それなりの効果があると思う。