Debugging – Why my Content Editor was so slow

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!

The only way that the AccessResultsCache would get 38,000 entries is if it had evaluated the security on a LOT of items. In fact, that’s likely the entire content tree.

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:

Yup, that query checks ALL items under the content node… what could possibly go wrong? Oh, I don’t know, evaluating permissions and caching 38,000 items? And the kicker is… this field is used once, and there’s only one item using that template. And it’s for the Sitemap – how often do we expect those settings to change? The whole damn thing should be controlled by a config file, in my opinion.

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.

Debugging – Why my Content Editor was so slow

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.