Since upgrading to Doctrine 1.2 my application has begun to get increasingly slower as hours elapse. I've pinpointed the cause to the new doctrine_cache_keys feature.
I've found at least three issues with this new method.
The key cache does not track enforce unique entries, thus multiple entries can be in the cache. See:
The doctrine_cache_key is being updated on every cache save or delete. With any caching strategy (APC, Memcached, Xcache) cache writes for the same key are (naturally) serialized. This leads to the "timebomb" situation described here: http://t3.dotgnu.info/blog/php/user-cache-timebomb.html
The problem is exarcerbated by the infinitely increasing size of the doctrine_cache_key array noted above. Depending on the caching engine, the lock time increases as well (APC & XCache free the previous entry inside the lock). This causes the application to spiral out of control, even with relatively trivial loads.
Personally, I don't think the "benefit" of having prefix/regex deletes is worth having this. Jon, you suggested having it disabled by default, but even with it enabled, this problem is reintroduced when someone decides to use it.
For most (maybe all?) cache engines the doctrine_cache_key seems entirely unnecessary.
- apc_cache_info('user') returns the list of cache entries
- $memcache->getExtendedStats('cachedump', $slabId) can return the list of cache keys
- According to the API docs xcache_list() behaves similar to apc_cache_info()
- a simple query can get this
- array_keys() ?
As this is currently broken for production use I intend to immediately fix both the first and second items above by preventing duplicate entries and disabling the doctrine_cache_keys behavior by default.
With more input/discussion I think the long term solution is to use the tools provided by the engines to get a list of keys, rather than maintain a list. I'd be willing to develop this as long as it is approved.