Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[2011-10-20] Partial cacheing degrades CMS performace #335

Closed
silverstripe-issues opened this issue Apr 3, 2013 · 1 comment
Closed

Comments

@silverstripe-issues
Copy link

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

@simonwelsh
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants