SharePoint 2013 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:
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()
To disable the developer dashboard, open the “SharePoint 2013 Management Shell” and type the following:
However, SharePoint 2013 developer dashboard is significantly revamped. In this article, I will cover some of the enhancements to SP2013 developer dashboard, cool? Okay here we go.
- First of all, the icon to launch it, is all metro-ified.
- Well you were sort of expecting that, weren’t you! 🙂 .. but there are some other exciting changes as well. When you launch the developer dashboard, it no longer sits on your masterpage. It launches in a separate window. This also means that “OnDemand” setting – is now deprecated – it doesn’t mean anything because it is OnDemand always. So when you pass in OnDemand – the API assumes you mean “On”. The only setting now is On or Off. This is great because it doesn’t interfere with your actual page.
This is how the new fancy dev. dashboard looks like now,
- And clearly you see a number of new enhancements, You see cumulative requests – not just the last request. This is incredibly useful when it comes to diagnosing the delta page loads that SharePoint 2013 is so famous for (I’m talking about MDM – I tweeted about this earlier). It also gives you an awesome summary of the page – like what server did the page run on – very useful with request routing in SharePoint 2013.
- The “Scopes” Tab shows you progress bar like views letting you easily identify the biggest performance pigs in your chain. In my code-mag article (I will link to it when it is live), I talk more about these scopes in depth.
- The SQL tab is also broken out nicely. What is super duper cool this time around, the individual stored procedures – well Microsoft offers you to look at the execution plan. Well damn, this is what I have been doing for a very long time because the documentation falls so short of giving you true guidance on how well does any SharePoint query perform. This execution plan, is a small step for Microsoft, but a giant leap for SharePoint architects.
- It shows you involved SPRequests in a separate tab – allowing you to easily diagnose leaked SP Requests. It also separates out assertions, service calls, and cache calls.
- And finally, perhaps the sexiest improvement is, it gives you a separate tab letting you correlate all ULS entries. YAY! Why is this a big deal? Because frequently an error on a page, isn’t occurring on a page – it is occurring in a service or process perhaps on another WFE. This is especially going to be more important given the new request routing capabilities in SharePoint 2013. ONLY ULS lets you piece together the whole picture nicely. So, being able to see the ULS log correlated with the actual page, is massively useful. Also, now you don’t need to sit on the server to read the ULS Log, you can get that through the browser (but remember you still need to run stuff on the server to enable developer dashboard, so this does not constitute a security booboo).
- Additionally, behind the scenes now the developer dashboard is implemented as a dedicated WCF service called “diagnosticsdata.svc”.
Thanks for following,