Blog

Sitecore Performance Analysis: Profiling, Debugging, Caching & More

December 14th, 2011

Content Management, Technical

The following blog post is part of a series on Sitecore optimization from the forthcoming NavigationArts’ whitepaper entitled “Advanced Sitecore Performance Optimization”.  View more posts in this series here http://blog.navigationarts.com/tag/sitecore-optimization/.

Out of the box, Sitecore provides a host of tools for performance analysis from within and outside the Sitecore authoring environment.  Since a large percentage of the potential to improve site performance comes from the interaction of developer code with the Sitecore environment, the following tools are invaluable in determining slow elements and configuration issues.

Profiler / Debugger

Tools for debugging and profiling pages are available from within the Developer Center (under Debug > Profiler) or from within the Page Editor (Preview pull down, click Debug).  Both methods allow a developer to view the profile and trace page events that occur in building the Sitecore page, as each control is expanded during load and then rendered.  The resulting profile can then be saved for permanent viewing.

Sitecore profiler running on a content page.  Note that the Information checkbox is rendered, and Sitecore is not caching any renderings.

This tool is invaluable in determining which renderings or controls are consuming the most time on a given page, but it can be deceptive. Time “cost” in rendering controls are aggregated up to a hierarchical object like a placeholder.  For instance, a content placeholder that has several complex sublayouts attached might take a long time to render, but the problem is not within the placeholder but the sublayouts themselves.  Divining information from the profile is further complicated by the increasing (and laudable) usage of fieldrenderer tags, which are their own controls and have their own rendering time associated.  This is valuable information, but sometimes superfluous to an optimization run that is looking for the big issues on a page.  At times it can be helpful to take a very dumbed-down approach and remove sublayouts that are suspected to have a significant performance for the length of running a profile, and then compare the timing to the page with those sublayouts present.

One particular ”aha!” with the profiler: if you are not seeing caching occurring in the profiler information, it is important to check to see if “rendering information” is disabled.

Note: When you enable rendering information in the Sitecore Debugger, Sitecore does not cache rendered HTML (output).To disable rendering information in the Sitecore Debugger, in the Rendering group, clear the Information check box.

Stats Tool

Sitecore records statistics for each rendering that is hit amongst the defined <sites> entries, which can be viewed via the following tool:

http://[instanceName]/sitecore/admin/stats.aspx

In modern installations of Sitecore, this page is protected from anonymous access, although it behooves a developer to make sure, as this information is not appropriate for public consumption.  The tool’s output is a simple HTML table which displays how many times each rendering has been called (in total, and from cache), the last run time for the rendering, and then the average/maximum/total for both times and items referenced.  Note that this tool is available on any instance of Sitecore (content delivery, authoring, development, etc) and the comparison between those environments is useful for determining expected versus real world usage.

Raw information from the Sitecore Stats Tool

Due to the prevalence of “miniature” controls like FieldRenderers in modern coding of Sitecore sites, there is a lot of data to sort through.  The key is to look for “larger” controls, such as sublayouts, that are responsible for more expensive and more logical chunks of code on a page.

A simple way to do this is to make the data easily sortable and filterable in Excel.  The following steps turn the HTML into a proper Excel table in Office 2010:

1. Create a blank worksheet in Excel
2. Switch to the stats.aspx page, then hit Control-A to select all, and Control-C to copy
3. Switch back to Excel and, with the top-left cell selected, hit Control-V to paste
4. Select the first row of data which contains the column name (Rendering, Site, Count, etc).  Then, holding down the Shift key, use the Page Down or arrow keys until all the header row and all the data is selected
5. On the Home tab, choose “Format as Table”, choose a style, and then select the default values.  Make sure to leave “My table has headers” selected.

Now the data can be filtered by columns, including setting minimum values, or sorted by individual columns.  An important first step is typically to exclude data from any site that is not “website” (or whatever you have named your primary front-end), so that you are not including data from sites like the shell that do not directly affect end users.  Also, it can be advantageous to remove renderings like “placeholders” from the statistics, as they do little work on their own, and basically reflect the roll-up performance cost of the sublayouts attached to them.

From an optimization perspective, there are two strong options to target by sorting from highest- to-lowest: average time, and total time.  Renderings with the highest average time are the heaviest workers in your installation, and are prime candidates for optimization. These renderings might be areas that have known issues with speed, or they might be surprises, but most importantly, they have numeric values associated with them to indicate their overall cost and potential for speed improvement.  This allows a developer to prioritize.

Renderings that take the most total time are even better candidates for optimization, because they reflect the combination of performance and usage, and renderings at the top of this list represent the biggest bang for your buck in terms of optimization.  Reducing the expensiveness of these calls might show less marked average time improvement, but is noticed by more total users.

What about items?  While it is a general goal to have renderings touch as few Sitecore items as possible, it is also difficult to determine if a rendering needs to touch that many items or not.  A good approach is to look at the queries taking place in renderings with an unexpectedly high number of items, and decide if the query can be optimized or replaced.  In general, if a rendering falls into this category, you should already know that it is one of the areas ripe for optimization [see the section on Analysis by Design]

Cache Tool

Like the stats tool, the cache tool is available in the admin folder of each Sitecore installation:

http://[instanceName]/sitecore/admin/cache.aspx

This tool lists out the caches internally managed by Sitecore for each site and data provider.  It does not refer to any .NET caches used by a developer outside of Sitecore.  For each cache, the tool displays the count of items in the cache, the current size, the delta (or change) in size from the last refresh, and the maximum size of the cache as determined via configuration settings.

A very easy to understand overview of what each of the caches does has been provided by Jens Mikkelsen in the following post:

Sitecore Caching – An Overview
Jens Mikkelsen

Getting back to the Cache Tool – what is it good for?  First of all, it contains the invaluable ability to manually clear caches without restarting the Sitecore instance, which can be very helpful – especially if the staging or scalability settings have not been properly set up to clear HTML caches on publish, though it should be used very sparingly to do this as performance can potentially suffer.

The web based Cache Tool.  Note that there are results for each site entry in the <sites> section of the config, plus additional Sitecore caches such as the AccessResultCache.

Secondly, it displays the maximum size of each cache.  Due to multiple places in the configuration in which that maximum size can be set, explicitly or as a default value, this tool serves as a check to ensure that size changes are being correctly applied, along with the Sitecore profiler.  The following blog post by Sitecore expert Alex Shyba explains in more detail:

How to verify HTML cache is working
Alex Shyba

Finally, and most significant to optimization, the tool shows how much each cache is being used and, with some refreshing, the turnover of each cache.

It is a natural inclination to look at the “Size” column, compare it to “MaxSize”, and start increasing the maximum size for those caches where it is bumping up close to the ceiling.  There can be value in this – many large sites have default values for HTML caches and database item caches that are too low for what the site has to serve.  But it is also dangerous, in that it can obscure real performance issues, or in some cases, make performance worse.

How is that possible?  A cache is not a magical device that always improves performance – rather it is a holding pen for frequently reused bits and pieces.  When it gets new data, it evicts older, “least requested” data in the hopes that this new piece will be used more frequently.  The more volatile the data in the cache is, the smaller the benefit it will impart to performance.  In a worst case scenario, a cache writes piece after piece of data to the memory or filesystem, and never re-uses any of the data, resulting a net negative performance gain due to the unnecessary writes.

This situation can be avoided by only using variance where it makes proper sense, and keeping an eye on the cache turnover.  That is where the “Delta” statistic becomes important.  By refreshing the cache page regularly, a programmer can determine how volatile the data in the cache is by how often the number changes once the site has hit a stable point after cache clearing.  An extremely volatile cache, especially one where the size goes up and down dramatically is either a sign that the cache is far too small, or that it is being poorly utilized.  This subject will be addressed in a forthcoming post in this same series.

Alan Gallauresi