Zend_Cache_Backend_Fileの限界点

ZendFrameworkのファイルをバックエンドとしたキャッシュは他のコンポーネントや拡張を必要としないのでお手軽に実施できます。
ただ、キャッシュエントリーが多くなるとキャッシュのクリアーなどで若干問題が発生するかもしれません。
複合的な要因で発生するようなので再現性や検証が難しいのですが。

事例：_cleanメソッド内でタイムアウト

高負荷なサイトでキャッシュの全クリアを実施したときに、Zend_Cache_Backend_File::_clean()のforeachループ内のis_fileとis_dirでタイムアウトして落ちるというケースがありました。（元々高負荷な状況ですので、30秒タイムアウトというのは余裕のあるラインではないのですが）
状況としてはユーザーリクエストで発生していたので、automatic_cleaning_factor による期限切れキャッシュなどの掃除が大量に発生していたようです。

考察

高負荷なサイトでは各種問題が発生しやすいのでフロントエンドオプションとしては、昨今ディスク容量には余裕があると思いますので、automatic_cleaning_factorについては緩めに設定して頻繁にガーベージコレクタが走らないようにしておくか、0にしてガーベージコレクタを止めて、管理機能で明示的にクリーンナップするかcron等で回すべきだと思います。目安としては、1時間に1回程度になるような数値で十分だと思います。また、もしクリーンナップ、もしくは期限切れチェックを行うだけでも負荷になるとすると、少ない頻度とはいえユーザーに遅延を感じさせることになるので、ユーザーセッション中のガーベージコレクションは避けた方がいいような気がします。
高負荷なサイトだと、バックエンドやDBへの問い合わせをなるべく減らしたいので、ファイルキャッシュはまぁまぁの選択だと思うのですが、statの負荷を考えると、バックエンドはSQLite等にした方が無難かもしれません。（試してません＝＞サーバーを増やした方が早いので）
一つ言えるのは、cleanメソッドに余計な時間がかかるようであれば、もうファイルキャッシュの限界点といえると思います。設計を見直す余裕がなければ、サーバーを増やしてスケールするしかないと思います。

そこはちょっと

Zend_Cache_Backend_File::_clean()でキャッシュのクリアモードがallの時、

<?php
            if ((is_dir($file)) and ($this->_options['hashed_directory_level']>0)) {
                // Recursive call
                $result = ($result) && ($this->_clean($file . DIRECTORY_SEPARATOR, $mode, $tags));
                if ($mode=='all') {
                    // if mode=='all', we try to drop the structure too
                    @rmdir($file);
                }
            }

こんな感じになっているのですが、modeがallのときディレクトリごと削除してしまうなら、再帰呼び出しはいらないと思うんですが、どうでしょう・・・