Performance Details in IntelliTrace

Performance Details in IntelliTrace

Rate This
  • Comments 8

As was introduced in the Microsoft Monitoring Agent blog post, the Microsoft Monitoring Agent provides a new capability to monitor IIS hosted applications and record performance violations in your application. Refer to the previous post and this MSDN article for details on using the Microsoft Monitoring Agent for monitoring your application and creating an IntelliTrace

Performance Data section on IntelliTrace summary page

After opening an IntelliTrace file that was created using the Microsoft Monitoring Agent running in monitoring mode you will see a Performance Data section that lists all of the recorded events that occurred when you application exceeded the performance threshold (default 5 seconds).


On the summary page you will see the entry point that triggered the violation. The following fields are shown in the Performance Data section:

  • Description – this lists the entry point into your application where monitoring detected the slowness
  • Duration (ms) – the duration in milliseconds that the request took to process on the server
  • Source – the web site and application that was monitored
  • Event Time – when the event occurred
  • Detail Level – when an entry point typically runs sufficiently fast and only occasionally exceeds the performance threshold minimal data is collected and the Detail Level will be “Limited”. If the very first request to an entry point exceeds the threshold or if the entry point has started to consistently exceed the threshold the Detail Level will be “Detailed” and will contain more information. Events with “Limited” Detail Level should be considered as informational and are typically not a cause for immediate concern.

Selecting a row and either double clicking or clicking the “View Details” button will take you to the details page for the performance event, a screenshot of which you can see next.

Details Page for a performance event

In the above screenshot you will see three sections.

Details – this section contains additional details about the process or machine that were captured by the agent. It is collapsed by default. Below is an expanded view.

Slowest Calls – this section lists up to 5 slowest calls that were detected when this entry point executed. They are listed in order of slowness. Clicking the “Find in Tree” link will expand the execution tree in the section below, if necessary, to show where the call occurred in the recorded execution tree.

Execution Tree – The execution tree is a tree of the calls that occurred and were recorded during the performance degradation.  This tree can be very deep with many branches. The “Expand All” link will fully expand all of the calls in the tree as shown below.

The slowest calls are identified using red text.

Some of the calls will have additional data available to aid in debugging and diagnosing the problem. These are indicated by the expansion icon on the Method Name. In the below screenshot the Action Execution: Home Index call was expanded to show the additional information. From here you can easily see the controller and action that were triggered as part of this request. Often you will find even more information captured in the parameters item that will provide information like parameters and values provided to SQL calls.

For any call in the execution tree you can select the call and click the “Debug this event” button. Typically you will want to select calls that are relevant to code within your application such as the FabrikamFiber.Web.Controllers.HomeController.Index() call.

In this case since I have stored the matching symbol and source files for my monitored application I will resolve to the matching line of source code. So when I click the "Debug this event" button I see something like the following screenshot.

For detailed information on the Microsoft Monitoring Agent refer to TechNet.

For expanded scenarios and usage information refer to MSDN.

We are always looking for feedback and comments for our features. Please visit the MSDN Diagnostics forums.

Leave a Comment
  • Please add 2 and 2 and type the answer here:
  • Post
  • if you can please the code and the method for this application

  • @Ben,

    The application that I used is a slightly modified version of the Fabrikam Fiber application included with Brian Keller's VM available here:

    The modification that I made was to the Index method on the CustomersController as shown in the screenshot above.  I did this simply to add a bit more complexity to the code and add some more database calls.

  • how can i decrease performance threshold?

  • Hello Larry. Can you please indicate how to reduce the default performance threshold for violations from 5 seconds to any other lower limit. I am looking for execution trees which I do not find when tracing with monitor mode. The trace mode is useful but for the performance threshold challenge.



  • @onuraltun, @Prithvi

    As a FYI the performance threshold is used to decide whether to log the event or not, so this is a value used during collection not during opening the file in Visual Studio.

    You can find the value within the collection plan that you are using, just look for the keyword PerformanceThreshold. The value is in milliseconds, so I expect you'll see a value of 5000. If you are not providing a custom collection plan, you can find and edit the default one here: C:\Program Files\Microsoft Monitoring Agent\Agent\PowerShell\Microsoft.MonitoringAgent.PowerShell

  • @Angelos  Thank you. I was looking for the threshold in the collection plans themselves (trace and monitor xmls) instead of the general config xml.

  • Your screenshots echo some confusion of mine.  Where is most of the time going when AllIncluding() is called?

  • @AlBran LVP What the screenshots are telling us is that AllIncluding took 15,277ms and the two subsequent SQL calls took 700ms and 211ms each. This leaves 14,366ms unaccounted for and your questions is where was this time spent? The best you can do with the data you have is to know that it did NOT go into the subsequent SQL calls, so by deduction it has to have been spent within AllIncluding itself.

Page 1 of 1 (8 items)