You can clone with
HTTPS or Subversion.
The menu cache currently gets cleared when pages are changed or deleted by connecting to the pre_save and post_delete signals.
This is an expensive operation when a site is large and there are timeouts on the cache to handle flushing these changes in an appropriate amount of time.
By the way, just discovered that this is getting done in the Page.save method as well which means that it happens multiple times.
The current strategy is to have the cache-timeout as high as possible, as the building of the menu is rather expensive as you noted. Short of more fine-grained caching or a way to pre-fill the cache, I don't see us changing this strategy any time soon.
I saw that the menu cache is not refresh when you just disable a page to "show on menu" and when you just "edit" her.
@digi604 , @ojii : I would like to investigate this issue, do you have recommendation on the way to go?
Should we add a "clear cache" option in the toolbar ? add a setting to make this refresh on page change optional ?
the chache version needs to be increased if something 'relevant' happens.
@digi604 : define relevant ? :) Should we only "fix" the fact that the cache refresh is triggered multiple times?
on the page:
multiple cache clears surely should be avoided
ack - putting this on my todo list
Hey all, just to provide some info to this. i recently added/updated, the page cache so that it uses a "Cache Versioning Strategy", so, this is about as inexpensive as it can get for cache invalidation, since everything, including the very keys we use for the cache, are stored in the cache itself.
Read here for more detail: https://github.com/divio/django-cms/blob/develop/cms/views.py#L296
I recently looked into retrofitting the menu cache to use a similar strategy. Unfortunately, such a change will not be a trivial exercise since the current menu cache mechanism needs to perform queries to be able to find the correct keys to clear. This is because there are multiple "dimensions" that the cached menu can exist within [ menu × language × site × ? ]. The existing code uses the database to store the keys, but more importantly, to provide the query mechanism required to find the keys to invalidate.
Perhaps someone with more brains and/or more determination than I can figure out how to implement this querying capability with the cache versioning strategy, then, invalidating the menu cache will be tremendously more efficient to the point that performing hundreds of invalidations back-to-back will have virtually no performance impact, and thereby addressing @benliles’ requirements and will generally make the whole menu cache more performant.