Archive for November 2009
When I first had a look at the Developer Dashboard in SharePoint 2010 I was a bit confused. The numbers shown in the nested unordered list on the left, representing load times in milliseconds, didn’t seem to actually cover 100% of the the request that was being handled. Basically it turns out that there are “gaps” that are not monitored, which is exactly why the sum of execution times for a certain set of child nodes in the list often don’t match the execution time of the parent. This is due to the SPMonitoredScope model.
Each node in the list represents a SPMonitoredScope that was created, either in SharePoint OOTB code or in code that you wrote yourself. When a second SPMonitoredScope is created before the first one is disposed, the second one will be treated as a child scope of the first one. In the context of a web request, the top level scope is instantiated in the SPRequestModule. Scopes that you instantiate yourself will most likely become child scopes of this “Request scope”.
Lets look at an example for a custom Visual WebPart that creates it’s own scopes.
1: protected void VisualWebPart1_Load(object sender, EventArgs e)
3: using (SPMonitoredScope mainScope = new SPMonitoredScope("VisualWebPart1_Load mainScope"))
5: Thread.Sleep(5000); // some processing that is not inside a subscope
7: using (SPMonitoredScope subScope1 = new SPMonitoredScope("VisualWebPart1_Load subScope1"))
12: using (SPMonitoredScope subScope2 = new SPMonitoredScope("VisualWebPart1_Load subScope2"))
17: using (SPMonitoredScope subScope3 = new SPMonitoredScope("VisualWebPart1_Load subScope3"))
Now let’s look at the resulting Developer Dashboard output.
Do you see what I mean?
Now on a similar note, I have been working on a project that visualizes the data rendered by the Developer Dashboard. It’s just not easy enough to spot “peaks” without it.
As you might have guessed, it’s a jQuery based solution. I am hoping to put it on CodePlex soon. Here is a sneak peek (click to enlarge):
Last week I published my fourth CodePlex project, called SharePoint LiveListData. It is an “assembly-free” solution which means that it contains no server side code. It is implemented as a jQuery plugin.
So what does it do? It uses AJAX to automatically reload any list-based Web Parts as soon as a change in the underlying list data is detected. You can also have your custom web parts refreshed, as long as they have a web part property that contains the ID of the list they depend on!
I have put online a screencast that demonstrates the the user experience.
Want to know how it works? Allow me to describe using some pseudo code..
- Make a single call to WebParts.asmx web service using AJAX to return an xml document with all web parts on the current page
- Parse returned xml and find all web part nodes that contain a ListID element (which holds the value for the ListID web part property)
- LOOP with interval = $configured_interval
- Make a single call to Lists.asmx web service using AJAX to retrieve “LastDeleted” and “Modified” properties for each ListID in the hashtable that was created earlier.
- For each ListID in hashtable
- compare values for LastDeleted and Modified with those values retrieved as part of the previous loop iteration for this ListID (unless it’s the first iteration).
- If any of the ListIDs are marked as UpdatePending
- Make an AJAX request to page that is currently loaded in the browser (allowing us to get a fresh copy of the current page containing the new list data)
- For each ListID marked as UpdatePending
- Replace div with matching WebPartID attribute in current document with “same” div in AJAX response (which contains the new list data).
This is basically how it works in a nutshell.
For examples on usage, check out the downloads tab on the SharePoint LiveListData CodePlex site, where you can also download the script!