There are only two hard things in Computer Science: cache invalidation and naming things.

-- Phil Karlton

BEAR.Sundayのキャッシュ

BEAR.Sundayではフレームワークが再利用する$appキャッシュの保存にAPC+ファイルのチェーンキャッシュを利用しています。APCのキャッシュが利用可能ならそれを利用し、なければファイルキャッシュを読み込みます。ファイルキャッシュもなければキャッシュを生成しますが、その生成タイミングでAPCにも保存します。

APCキャッシュは取り扱い注意

チェーンキャッシュを採用する理由はコンソールでの操作、つまりdeployツール使用時にコンソールの操作でキャッシュを生成するためです。APC関数はwebスクリプトでしか利用できないため、APCにデータを保存することができません　（apc.cliオプションの設定はエラーを出さないだけです）

削除も同様です。コンソールからの消去はできないので専用のスクリプトやAPC付属のapc.phpを用意する必要があります。認証も必要でしょう。deployプロセスに組み込むのも面倒です。

APCキャッシュはwebサーバーに対してグローバルなのでapc_clear_cache()を行うと同じwebサーバーで動作する他のアプリケーションもあれば影響を与えてしまいます。

webでしか動作しない。グローバルでキャッシュのグルーピングができない。ーとかくAPCキャッシュは取り扱いが面倒です。CakePHPは以前、APCキャッシュがデフォルトだったのをファイルキャッシュに戻してしまいました。

多くのフレームワークがファイルキャッシュをデフォルトにしています。ファイルキャッシュは取り扱いは簡単ですが速度は劣ります。

安全なキャッシュクリアの方法

A) 新しいプロジェクトフォルダを用意してsymlinkでリンクを貼り直します。

または

B) srcディレクトリの日付を更新します。

touch src

APCキャッシュは実際には消去されず、キャッシュIDが更新されるために以前のキャッシュが無効化されます。（srcのタイムスタンプをキャッシュキーに含んでいます）

コンパイル

コンパイルとはDIとAOPのPHPコード生成を含むキャッシュの手動生成です。

キャッシュがない状態のアプリケーションを実行すると最初の実行でキャッシュが生成されますが、高負荷のサイトではその負荷が問題になります。

キャッシュやPHPコードを事前に生成して置くとその問題を避けることができますこれをコンパイルと呼びます。コンパイルは全てのページクラスのファクトリーコードも生成するので、DIの依存解決に問題があればアプリケーション実行前に検知可能です。

vendor/bin/bear.compile 'Polidog\Todo' prod-html-app /path/to/project

リソースキャッシュ

キャッシュには以下の種類があります。

DIの設定で作られるPHPの生のファクトリーコード　(tmp/ディレクトリ)
メソッドインターセプターを可能にするAOP用のコード　(tmp/ディレクトリ)
ルートオブジェクト$appのキャッシュ
リソース（リソースステートや表現）のキャッシュ

（最初の２つは自動で生成されるPHPのコードですがここではキャッシュとして扱います）

リソースキャッシュはアプリケーションのキャッシュで、apcやファイルキャッシュ以外のキャッシュストレージ、つまりredisやmemcacacheを利用しているときにはキャッシュを無効化するかしないかをCacheVersionModuleで決定することができます。

$this->install(new CacheVersionModule('1')); // リソースキャッシュのバージョン指定

アプリケーションのキャッシュが再利用できる場合にはバージョンをそのままに、再利用できないプログラムの変更を行ったらバージョンをあげると無期限指定のキャッシュをも消去します。deployまいに全部消去するなら日付時刻を指定すればいいでしょう。

.do_not_clearファイル

prod-またはstage-のプリフィックスがついたコンテキストだけです。それ以外はキャッシュは保存されません。

それ以外のコンテキストでファイルキャッシュを有効にするためには、var/tmp/{context}の中に.do_not_clearというファイルを設置すればそのフォルダのファイルは消去されなくなります。