A very long time ago, I wrote an article, “The 12-Step Recovery Program from a SharePoint Error,” CODE Magazine, Jan/Feb 2011, QuickID 112031, which walked you through a definitive 12 steps to help you isolate any SharePoint issue. One of the top techniques I mentioned in that article was the Developer Dashboard. Using the Developer Dashboard is quite simple - you activate it, and it appears on the page. But there is so much more to it than that. In this article, I will take a deep dive into the Developer Dashboard.

What Is the Developer Dashboard?

The Developer Dashboard is an integral part of a SharePoint 2010 page that shows various information about the rendering and behind-the-scenes action of a SharePoint page. It is not something you need to install, but it is something you need to enable. You can enable it using a command as shown below:

stsadm -o setproperty -pn
developer-dashboard -pv OnDemand

You can also enable it using PowerShell using the script below:

$d = [Microsoft.SharePoint.Administration.
SPWebService]::ContentService.
DeveloperDashboardSettings;
$d.DisplayLevel = 'OnDemand';
$d.RequiredPermissions = 'EmptyMask';
$d.TraceEnabled = $true;
$d.Update()

When activated as above, it can then be enabled on demand by clicking on an icon that appears by your name on the top right-hand corner of the SharePoint page. This icon is the SharePoint:DeveloperDashboardLauncher control. Alternatively, you can access it by appending ?DeveloperDashboard = true as a query parameter on the URL. Note that the above commands make the Developer Dashboard available on demand, with no specific permission requirements - you can obviously tweak this as necessary.

You can see the Developer Dashboard in Figure 1. This is the SharePoint:DeveloperDashboardControl in your master page.

You can see two halves of the Developer Dashboard. On the left-hand side, you see what portions of the page took how much time to render - broken by component. You can easily tell which component might be causing the page to slow down. Also note a green border around the Developer Dashboard. That indicates a page that is rendering relatively fast.

The right-hand side contains various sections.

  1. Web Server. This section gives you some basic overall information about the page. Perhaps the most interesting piece here is the correlation ID. If you are running into an error that is not manifesting itself on the page as an error, you can use the correlation ID to correlate all the behind-the-scenes components from the ULS LOG inside of SharePoint.
  2. Asserts and Critical Events. Shows you obvious exceptions and errors on the page.
  3. Database Queries. Will literally tell you what stored procedures were executed in the rendering of the page, and what parameters were passed to the stored procedure. You can click on the name of the stored procedure to find more information. Go ahead. Do an IIS reset and hit F5 - you will see database and service calls to be slightly different the first, second and third time. It also tells you how long each stored procedure took so if the database is your bottleneck, it becomes quite clear from here.
  4. Service Calls. Tells you what WCF services were called as a part of rendering the page.
  5. SPRequest Allocations. SPRequest allocations are necessary but expensive. This section displays SP Request allocations and can be used to check whether or not SPRequest objects are properly set to dispose. For example, clicking on the link for the SPRequest object shows details, as shown in Figure 2.

At the very bottom of the Developer Dashboard you see a link to show/hide trace information. Tracing is very similar to ASP.NET tracing, and it will give you a ton more information about the page’s rendering.

The DeveloperDashboardSettings Class

The eagle-eyed of you may have noticed that in the PowerShell script I used to enable the Developer Dashboard, I used a class called DeveloperDashboardSettings. This class allows you to further tweak the behavior of the Developer Dashboard. For instance:

  1. It has properties such as MaximumCriticalEventsToTrack and MaximumSQLQueriesToTrack that put limits on the amount of data the Developer Dashboard tracks.
  2. The DisplayLevel property allows you to set it to Off, On or OnDemand.
  3. The RequiredPermissions property allows you to require a user with only a certain permission level to be able to view the Developer Dashboard.

The SPMonitoredScope Class

You can use the SPMonitoredScope class to monitor performance and resource usage in a code block of your application. You cannot use it in sandboxed solutions. Using it is quite simple:

using(new SPMonitoredScope("Scope"))
{ // your code goes here }

The code inside the SPMonitoredScope will get logged inside the Developer Dashboard and ULS (Unified Logging Service). You can also nest these scopes to get a breakdown of different code blocks within a monitored code block.

While the SPMonitoredScope class is not available in sandbox solutions, you can implement your customer monitor by implementing the ISPScopedPerformanceMonitor interface. Lucky for us, you can use the ISPScopedPerformanceMonitor in sandbox solutions.

Some of the common out-of-the-box classes that implement ISPScopedPerformanceMonitor include:

  1. SPCriticalTraceCounter. Traces critical events and asserts.
  2. SPExecutionTimeCounter. Allows you to track execution time for your scope.
  3. SPRequestUsageCounter. Allows you to track the number of SPRequest objects your code uses.
  4. SPSqlQueryCounter. Tracks the number of SQL queries for your scope.

Developer Dashboard in SharePoint 2013

The Developer Dashboard is an invaluable tool for a SharePoint developer. It is therefore not a surprise that Microsoft has continued to innovate and improve upon this essential feature in SharePoint 2013. All that I mentioned in this article is equally applicable to SharePoint 2013, but if you are interested in learning about the specific improvements and changes to the developer dashboard in SharePoint 2013, you should read my article here: http://blah.winsmarts.com/2012-7-SharePoint_2013_Developer_dashboard.aspx.

Summary

The Developer Dashboard provides an immense leap forward in being able to write good code for SharePoint or to be able to diagnose issues with SharePoint. It is something that you should get in the habit of using regularly. I’ll be back in my next article with more exciting tips, until then, Happy SharePointing.