created by: Jules
created at: 2011-10-20
original ticket: http://open.silverstripe.org/ticket/6749
With several hundred files in the silverstripe-cache/cache directory, it can take 10 seconds for common CMS functions like displaying SilverStripeNavigator, loading a page in the CMS, or publishing a page. A partial cacheing scheme that results in >100 files has a noticible negative effect on normal CMS usage.
This makes partial cacheing suitable only for small sites, or where per-page cacheing is avoided e.g. cache common HTML like menu & footer, and a few expensive pages like sitemap.
The cause is in Line 53 of Aggregate.php where Aggregate::flushCache calls Zend_Cache_Backend_File->clean, which opens, reads and unserianlses every metadata file (so half the files) in the cache. e.g. When a page is published, Aggregate::flushCache is called 9 times.
I doubt the problem is inherent in the Zend cache because it is so generic. It's more likely to be the way SilverStripe is using it.
DataObject::flushCache has an optional parameter, '$persistant=true', but the parameter is never provided. Changing the default to '$persistant=false' restores normal CMS performance for all operations.
DataObject.php line 2828:
public function flushCache($persistant=false) {
This points to a solution, but I don't think it's THE solution and I don't know what the side-effect are, apart from the cache never being cleared.
Even if DataObject::flushCache(true) is called in one strategic place, it would be too slow. The problem is either the way SilverStripe uses the cache, or the cache mechanism itself.
Zend_Cache_Backend_File->clean has filter options to clear selectively. Maybe Aggregate::flushCache could be changed to be more selective.
This issue was initially raised in the forum:
http://www.silverstripe.org/general-questions/show/18342