You have a SharePoint Server 2010 Service Pack 1 (SP1) server farm. A webpage designer recently
modified the home page of a site and added several custom Web Parts to the page. Users report
that the home page takes a long time to load. You suspect that a Web Part causes the home page to
load slowly. You need to identify which Web Part causes the home page to load slowly. What should
you do first?
A.
Open Performance Monitor.
B.
Enable Microsoft SQL Server Reporting Services.
C.
Enable the Developer Dashboard.
D.
Open PerformancePoint Dashboard Designer
Explanation:
Using the Developer Dashboard
SharePoint 2010 4 out of 11 rated this helpful – Rate this topic
Published: May 2010
The Developer Dashboard is an instrumentation framework introduced in Microsoft SharePoint
Foundation 2010. Similar in concept to ASP.NET page tracing, it provides diagnostic information that
can help a developer or system administrator troubleshoot problems with page components that
would otherwise be very difficult to isolate. For example, a developer can easily introduce extra
SPSite or SPWeb objects into his or her code unknowingly or add extraneous SQL Server queries.
In the past, the only way to debug performance problems caused by the extra overhead of these
instances in code would be to attach a debugger to the code and monitor SQL Server Profiler traces.
With the Developer Dashboard, a developer can identify this type of problem, either
programmatically by using the object model or visually by looking at page output.
Although performance issues and resource usage information is available in the Unified Logging
Service (ULS) logs, interpreting the raw data can be very time consuming. With the Developer
Dashboard, all the related information is correlated, which makes identifying these types of issues
much easier.
What Information Is Captured?
Developer Dashboard contains an extensible mechanism for measuring various performance
counters at various scopes. Within Developer Dashboard, the following performance counters are
used to monitor usage and resource consumption at each stage of the requests.
Per-Thread Counters
These counters measure values for the current request or timer job:
Thread execution time
Number, duration, call stack information and query text of each SQL Server query generated by the
page
Number, duration, and call stack information of each WCF call
URL or timer job name
Current user
Execution start time
Any of the preceding statistics for code enclosed by SPMonitoredScope (see Using
SPMonitoredScope)
The preceding data is output to two locations at the end of every request or timer job:
ULS log — All collected statistics for a specified scope are always logged to the ULS log.
Developer Dashboard — Performance statistics for a request are available in the browser window.
http://msdn.microsoft.com/en-us/library/ff512745.aspx