Picking apart CRM 2011's diagnostics page - Part 1

A few days ago I was called in to examine client-side CRM 2011 performance issues. I love a good examination process that lets me dig in!
After going through the obvious culprits such as update rollups, installed antivirus software, client and server specifications etc. it eventually turned out to be a server I/O problem which was causing longer than expected load times. I used HTTP Watch and WireShark to point me in that direction and then had some discussions with the IT team.
All that, however, wasn't the interesting part. Not even close.

During this examination I used CRM 2011's diagnostics page (http://<server>/<org>/tools/diagnostics/diag.aspx or http://<server>/tools/diagnostics/diag.aspx). This was part of CRM Online that came to the on-premise version in Update Rollup 4. More about that in Rhett Clinton's article. The reason I started picking apart the diagnostics page was because I was getting fairly good results despite CRM behaving worse than expected. Seeing that, I decided to check what exactly the diagnostic pages does and measures. Below is a sample of this page from one of my test systems.


CRM 2011 Diagnostics Page

One thing I'd noticed about the diagnostics figures is that they vary greatly between different networks and client computers. What does seem fairly constant (putting aside any real issues) is the ratio between the 4 JavaScript sections. While the number may vary, the Dom Benchmark will always be the longest and the Base64 test will always be the shortest.

The first thing I did was to understand what each of the tests stands for. These are as follows:

1. Latency Test
   Not exactly what I'd call a latency test but as close as you can get with HTTP. This calculates the average time taken over 20 downloads of a very small text file (only 12 bytes long).
   The file downloaded is /_static/Tools/Diagnostics/smallfile.txt
2. Bandwidth Test
   Performs downloads of image files in increasing size. Slightly similar in concept to many Internet based speed test sites. These download speeds are then averaged out (weighted of course) to give one average download speed value.
3. Browser Info
   Basic JavaScript pull of the local browser details such as browser name, version, cookie status, platform (OS) and the user-agent string.
4. IP Address
   Reports the IP address of the client computer as known to the server. This is passed as a variable in the diag.aspx file. The IP address is server-side dynamic and represents the IP address which was used to contact the server with.
5. JavaScript tests (there are 4)
   Runs various JavaScript times loops and returns their execution time. This is basically a memory/CPU stress test on the client machine. I will elaborate more on thest in Part 2 of this article.
6. Organization Info
   Basic server info such as organization name, time on server and url.

These tests output quite a lot of useful data to the Results text area. When running these tests I highly recommend looking at that and not just the values in the results table.

In the second part of this article I will dive into the JavaScript tests phase. If you're like me, that's the most interesting part. :)