First off, if it is a specific page that seems to be causing slow downs, you probably want to verify that the page doesn’t have any “Closed WebParts”. A closed web part is a web part that is still being processed by the .NET framework, but that never actually gets displayed on the page. In order to view all web parts on a page, you’ll need to switch to the web part page maintenance administrative page. This can be achieved by appending the following querystring parameter in the page’s url:
On this page, you’ll see a list of all web parts that have to be processed for the page to load. The column we are interested in is the “Open on Page?”” column, which indicates whether or not the web part is closed on the page. The following screenshot shows you an example of a page that has two Web Analytics web parts that are closed. Note that none of these two web parts are actually displayed to the user when loading the page.
Now, in order for the page to stop processing them, we will have to select them both, using the checkbox beside the web part’s’ titles, and then click on the Delete menu at the top. Take good note of the Caution message at the bottom of the page, doing this will actually edit the Shared version of the page, that’s the version accessible to everybody. If you want to only edit the personal view you’ve created for the page, you will have to click on the “Switch to personal view” menu. All of this can also be achieved using SharePoint designer, but details on how to do it with this tool are not covered in this article.
The second option you have to troubleshoot a specific page’s performance, is the Developer’s Dashboard. This is a new feature Microsoft introduced in SharePoint 2010, and requires some configuration settings to be set in order to use it. The developer’s dashboard is a neat little utility that allows administrator to view details about a specific page’s processing, and drill down into each components of it to help identify bottlenecks.
The display property of the dashboard can take 3 values: on, off, or ondemand. On demand will provide the user with a dashboard icon beside personal menu a the top right of the page, allowing them to show and hide the information panel. The on-demand mode is probably the one you’ll want to use. Below is a short PowerShell script I have developed to allow administrators to activate the Developer’s dashboard. This script should be run inside the SharePoint 2010 Administration Shell.
$spwebapp = Get-SPWebApplication http://localhost
$devDashboardSettings = $spwebapp.WebService.DeveloperDashboardSettings
$devDashboardSettings.DisplayLevel = “ondemand”;
$devDashboardSettings.TraceEnabled = $true;
The following picture shows the developer’s icon once the settings has been set to ondemand:
Clicking on this icon will automatically open and information pane at the bottom of the screen. This panel contains information about loading time for each of the various components of the page. In the example below, we see that the two “closed Analytics Web Parts (the same as the example above). are taking a combined total of 0.19 ms to load.
You can also get other very useful information from this panel such as how long it takes the Search Scopes drop down to be populated, the wiki conversion time, and so on. You can also view details about Critical errors and warning issued by the Health Analyzer service from within this panel. The example above shows that three configuration warning were reported. Clicking on the associated warning id will automatically launch a second windows describing what the error/warning is all about, and how to go about it. Now, assuming you are not happy with the information provided, and need to go even more granular, Microsoft is allowing you to open the stack trace and see exactly what has been executed on the page. This was enabled by the $devDashboardSettings.TraceEnabled = $true; line in my script above. Setting the trace value to true, adds a link at the bottom of the information panel named “Show or hide additional tracing information…”. Clicking this link will load an extensive list of all the various .NET, database, and IIS calls that were made by the page. This comes in very handy when trying to debug custom code, since it allows a developer to see exactly how long each method took to execute. The following screenshot shows an example of trace entries reported by the developer’s dashboard:
To wrap it up, SharePoint provides you with several ways to troubleshoot performance issues, you just need to take the time to analyze all the information that is provided to you.