Developer Dashboard in SP2010 and new 2013

Have you ever told to figure out why your SharePoint page is consuming much time? In projects where the page render SLAs are at an aggressive end - like one of my current project - we SharePoint engineers will have a real good time...

In the older versions (MOSS 2007, SPS 2003) this was too tuff - personally I used to follow a manual approach in isolating the issue by removing web parts one by one etc... I believe SharePoint product team invested a lot and came up real good feature in SP2010 named Developer Dashboard.

Developer Dashboard is designed to provide additional performance and tracing information that can be used to debug and troubleshoot issues with page rendering time.  This used often by the administrators whenever there is a need to identify / improve page performance. Enabling this great feature will help you get critical information about execution time, log correlation ID, critical events, database queries, service calls, SPRequests allocation and web part events offsets etc.

We can set the DashBoard in the following 3 levels

OnDemand. : In this mode you should see on the left hand side of the ribbon a small icon next to the login credentials. On clicking that icon - SharePoint will toggle the dashboard display beneath the page output. This toggle option will be available only to site collection admins. Looks promising right...

On. :  In this mode you will not see the small icon at the top of the page but the Developer Dashboard will be available on the bottom of your entire page always.

Off. : In this mode you neither see the dashboard nor the icon to display it.

By default the Developer Dashboard will be turned off - it can be enabled easily using object model code, STSADM commands or PowerShell script.

The following script/command will enable developer dashboard in "OnDemand" mode. To switch it on and of , use "on" and "off" parameter values respectively.

PowerShell

$sp =[Microsoft.SharePoint.Administration.SPWebService]::ContentService.DeveloperDashboardSettings;

$sp.DisplayLevel = [Microsoft.SharePoint.Administration.SPDeveloperDashboardLevel]::OnDemand;

$sp.RequiredPermissions = 'EmptyMask';

$sp.TraceEnabled = $true;

$sp.Update();

STSADM

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

Object Model

SPWebService sp = SPWebService.ContentService;

sp.DeveloperDashboardSettings.DisplayLevel = SPDeveloperDashboardLevel.OnDemand;

sp.DeveloperDashboardSettings.Update();

Note: DeveloperDashboardSettings has a property called RequiredPermissions.  You can assign a collection of base permissions (like EditLists, CreateGroups, ManageAlerts, or whatever you want) to it; only those people that have those permissions will be able to see the output.

Note: Developer Dashboard is a farm level setting. So If you code the above object model snippet  up in a web part and try to execute it in a non-central admin site, it will throw a security exception.

Note : code from Sandboxed component won’t be showing up in Dashboard since its running in completely different process from the page request.

What is there in Dashboard

In the Dashboard you will find information about the controls, queries and execution time that occur as part of the page rendering process. Usually it provides information from the perspective of the event pipeline, the web server and database. On the left side you can see the different events that fired in the page processing pipeline and its processing duration.  On the top right hand side you see information about the page processing as whole, including the overall execution time, the amount of memory used in the processing of the page request and the correlation ID. Correlation IDs are great info when trying to link the page render to entries in the ULS log.  Underneath the server information you will find a list of the different database calls that were made through the object model by various components in the page itself as well as the controls it hosts. There is an additional option to to see the call stack of every database call - by clicking the database call hyperlinks.

Why to use SPMonitorScope as a best practice

Developer DashBoard does not display the entire set of events instead the code you have in your override for OnInit or Render will be captured in this pipeline.  To ensure the trace of code in other places use the new object model class called the SPMonitoredScope it helps to keep track of useful usage and tracing information just like the developer dashboard uses. You may use it as shown below

using (SPMonitoredScope scpBtnGetScore = new SPMonitoredScope("BtnGetScore_Click"))

{//add your custom code here}

In my understanding this is the only option to understand an manage the custom components once you deploy it in PROD.

Whats new in SP2013

Developer Dashboard in SP2013 is using dedicated WCF service (diagnosticsdata.svc) it allows Detailed request information per page with chant view and additional detailed information included for request analyzing. There is an Interactive addition in the new Developer Dashboard with which you can now View ULS logs (under a dedicated tab) for particular request. This will definitely save developer since it avoids the dependency with admin teams to get ULS logs that they need. Now Developer Dashboard is running in separate window to avoid affecting rendering of actual page.

Don’t know why the OnDemand option is deprecated: Only ON & OFF settings are available. Will share more details soon...