We are currently experiencing huge performance penalties when using the "Include all subsites" navigation setting combined with a large number of SPWebs with non-inherited permissions. This penalty only occurs every few requests, most probably based on some concurrent usage elsewhere within the site collection. At this point we have worked around the issue by leaving this navigation setting off and moving over to manual navigation settings. This hugely impacts our maintenance efforts as one could imagine.
I am trying to understand the underlying caching mechanism. As far as the documentation goes (interestingly we need to refer to 2007 documentation: https://technet.microsoft.com/en-us/library/cc298466(office.12).aspx ; can't find any reference to navigation data in the object cache within 2013 documentation), and the SharePoint developer dashboard is revealing, the navigation is being cached in the publication infrastructure's object cache.
And indeed, as soon as we invalide the complete object cache through site settings, it takes more or less the same time (10-30 secs) to rebuild the navigation data as we were experiencing.
So we all thought we understood the mechanism: every 60 secs the object cache gets invalidated and the navigation data is pulled from the database.
But alas (or luckily), we have a case with a huge set of spwebs (2000+) with the include subsites setting enabled, that is not experiencing performance issues. Within this site collection the permissions are largely inherited.
But as soon as we invalide the object cache it takes forever (100+ secs!) to pull the navigation data from the database.
Why aren't we experiencing that during normal use of this site collection?
We have a couple of hypotheses:
- The object cache with regards to navigation data is not invalidated every 60 secs. It is updated dynamically;
- Cached data with non-inherited permissions gets invalided much more often;
- There is some side-process going on outside the user's web requests responsible for building up the navigation cache.
When walking through the Microsoft.SharePoint.dll assembly using a decompiler I see two paths with regards to cache:
- A path where SPNavigationProvider is calling into the SP.SPRequest COM-layer to retrieve cached data (implementation found in owssvr.dll; I don't have the source code for this binary);
- A path where CacheObjectFactory is called to build up the ObjectCache for all SPWebs (among others).
Unfortunately I am not able to correlate any further. We are using SharePoint 2013 Server 15.0.4805.1000 March 2016 update.