Skip to content

How to investigate slowness with PerfView

Jump to bottom
Nikolay Mitikov edited this page Jun 8, 2018 · 10 revisions

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 developed by Microsoft performance architects- just 2 clicks to collect the needed data:

perfview-collect

Important to select Thread Time:

perfview_2018-06-07_17-54-47

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 start, the more useful information you have.
  2. A few 2 long profiles are far better than one hour long

Please do NOT collect profiles longer than a few minutes.

In the demo we are interested to investigate what affects Experience Editor opening performance, thus the preparation step would be to login to Sitecore.

Collection time

  1. Start the collection
  2. 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 operation. This shall filter out FileWatchers and background operations
  • 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:
    • CorePipeline.Run -> just invoke processors one-by-one
    • dynamicClass -> Sitecore Reflection feature allowing fastest method call
  • Swithcing to the Flame graph view we can hover over bars to find what slows us down

Clone this wiki locally