A customer reported to me that their content editor would freeze for 5 minutes if you clicked the root node of their site in Content Editor. I was surprised – bit when I went and did so, it froze for 5 minutes.
Now, this was on a newly upgraded and replatformed system, so I when and tried their existing system – and had the same result. The first click on the root node would take 5 minutes to load. So, it wasn’t our upgrade – but that I could study more easily. As it was the first click only, I figured caching was involved – but what gives? How do I find out what’s going on?
I started by checking my local development instance, but it did not show the same problem. But it isn’t an accurate replica of their production system; I have hardly any content.
Well, I wrote a page (pretty much the same as /sitecore/admin/cache.aspx) to check the cache sizes (I use this on CD servers for cache tuning, but it makes for prettier screenshots too). I cleared the caches, checked their sizes, clicked on the root node, waited 5 minutes, and checked again. I noticed a few things:
The AccessResultsCache before the click:
And after the click:
Holy carp! That click resulted in 38,000 entries in that cache, and 200MB of data. Also, my Prefetch cache was going nuts!
At this point my spider-sense started tingling. Something about an item that causes a big tree to be evaluated … I started to suspect a query on a Source field of a Field in a template that traverses a big section of the tree, and causes the permissions on all those items to be evaluated, and then caches all those items. Hence very poor performance on first load.
The root node had quite a number of interface templates, but eventually I found this:
Anyway, I changed the query to target a smaller branch of the tree – you know, the bit where all the settings go – and my first load time dropped to 3.3 seconds:
The lesson here is that Sitecore Queries, unless treated very carefully, can hammer your system.