Using SPMpnitoredScope

Sharepoint 2010 introduces the SPMonitoredScope class to allow developers to designate portions of their code so that they can monitor usage statistics in the Unified Logging Service (ULS) logs and the Developer Dashboard.

A developer can use SPMonitoredScope to (1) Identify excessive resource usage, (2) Identify performance bottlenecks and (3) Determine how certain component interact with other components.

SPMonitoredScope is in the Microsoft.SharePoint.Utilities namespace.

How to use it? A developer simply “wraps” the section of code to be monitored. Then, as the code is executed, the measured statistics are written to the (1) ULS logs as well as to the (2) Developer Dashboard. This allows information about the component and the page where it resides to be immediately available to the developer and to the system administrator.

using (new SPMonitoredScope(“My Scope Name”))

{

doSomeWork();

}

This code measures and logs execution time, number of requests, and the number of SharePoint SQL Server queries (including the query text) that are performed by the external callout.

using (new SPMonitoredScope(“My Scope Name”,TraceSeverity.Verbose,1000,

   new
SPRequestUsageCounter(3),

   new SPSqlQueryCounter()))

{

    callExternalCode();

}


SPMonitoredScope can also be used to dynamically trace only when excessive resource use is detected.

In the example above, the scope is being told that the callExternalCode() method should take no more than 1000ms, and that it should allocate no more than 3 SPRequests. If these limits are exceeded, the trace level for this scope will be increased to “high” for this one instance. The counter will also appear red in the dashboard.

Using SPMonitoredScope to wrap code has a very low performance
hit. However, it should be noted that if a section of code wrapped by SPMonitoredScope were to contain a loop that performed a high number of iterations
(for example, iterating through XML nodes that are returned by a SharePoint Foundation 2010 Web service), the call stack included on the Developer Dashboard could increase in size exponentially, making it difficult to decipher the information displayed.


Advertisements
Post a comment or leave a trackback: Trackback URL.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: