You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 is a problem with the Zend_Cache_File backend. Use one with better support for cleaning that looping through every item in the cache to check if it needs to be cleaned instead.
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
The text was updated successfully, but these errors were encountered: