How to investigate slowness with PerfView

Agenda

The article shows how to figure out where the delay is coming from.

We'll try to understand the nature of the Experience Editor opening speed and potential steps to improve it.

The game plan is:

• Record the video showing what are threads doing
• Find the slow operation in the video
• Figure out what makes it slow

Step uno - configure profiling

We'll use the free PerfView by Microsoft - just 2 clicks to collect the needed data:

Important to select Thread Time:

Once you push Start Collection data needed in 98% cases is already picked.

Step dos - prepare the operation

1. The closer profiling session matches the slow operation timing, the less noise you get
2. A few 2 long profiles are far better than one hour long

Please do NOT collect profiles longer than a few minutes.

The demo is to investigate what affects Experience Editor opening performance, preparation = login to Sitecore.

Collection time

1. Start the collection
2. Perform slow operation (Request Experience Editor page)
3. Stop collection after page fully loaded

Please refer to the video for more details.

Analysis time

The definitive description of the steps from How to analyze the PerfView profile with thread time data video:

• Advanced group already ships with a cooked report Thread Time (with Tasks) Stacks - just open it
• Add the values to the IncPats textbox to filter out tons of non-needed data:
  • Sitecore to only include frames having smth to do with our application
  • System.Web to only include frames dealing with Web operations (filter out FileWatchers and background workers)
• Find the heaviest thread by ordering frames Inc column and adding it to IncPats filter
• Hiding the noise done by fast operations by setting Folding to a few %
• There are well-known empty methods that do not cause any load and can be Folded to simplify the graph, examples:
  • CorePipeline.Run -> just invoke processors one-by-one
  • dynamicClass -> Sitecore Reflection feature allowing fastest method call
• Switching to the Flame graph view we can hover over bars to find what slows us down

Our example shows System.Web.Compilation.BuildManager.GetCompiledType consumes a big pile of time.

What is next?

• Review the source code for any obvious reason
• Debug the code with runtime values to see what is so specific here
• Create a micro-benchmark with current code VS suggested measuring the performance gain/win