Using Microsoft's Latest Network Tool to Diagnose Low Website Performance

Obviously, it is not always necessary to pull out heavy tools in order to identify a performance bottleneck. In many cases a simple network traffic capture using the browser's developer tools will provide valuable information. They are, however, not available on mobile devices and do not provide detailed information about the server-side of things.  

I recently had a problem with low website performance occurring only from mobile devices. So I decided to give Microsoft's latest network tracing tool Microsoft Message Analyzer a spin (from now on called MMA). It replaces Network Monitor. The ambition with this next generation, they say, is to create a tool that is better equipped for analyzing and diagnosing problems rather than mostly presenting the raw data like Network Monitor, Fiddler and WireShark.

So I downloaded and installed the free tool on my laptop. This enabled med to get started immediately instead of going through the bureaucrazy of getting it installed in the corporate enviroment of the customer. First I needed a log file with data to analyze. Message analyzer uses the existing Event Trace Log file format .etl. So I started a trace session on the Web Front End (a SharePoint WFE), recreated the problem by visiting the site with an iPhone and then ended the session again, so my log file would not grow larger than necessary. The following two commands were used in Powershell on the WFE:

netsh trace start scenario=NetConnection capture=yes report=yes persistent=no maxsize=1024 correlation=yes traceFile=C:\Logs\NetTrace.etl

netsh trace stop

When I opened the file in MMA I had to first organize the information shown in the analysis grid.  1) I Chose HTTP in the Layout dropdown to have a starting point. 2) Selected appropriate columns via right click on grid header. 3) Filtered the information via Edit Session or View Filter to narrow the data down to the traffic I generated with the iPhone.

That gave me a table with all the information about my requests that I could drill into.

It told me a few things: The main request to the page home.aspx took the server 12 seconds to respond to. So the code on that page definitely needed a review (and yes I found the coding problems that had to do with malfunctioning caching code - but that is a different story). Second this view told me that there was a 14 second time lapse before the server even began to respond with data. The time was consumed between the server denying an anonymous request (HTTP401) and receiving the correct follow-up Kerberos authenticated request from the iPhone. So definitely there was second problem causing authentication on the client to take up a very long time.

The Next step was to set up tracing on hardware in the client end, that is, the iOS devices. This was done by using a PC as a hotspot and capturing iOS traffic from there. Traces showed a multitude of Kerberos traffic in the form of TGS REQ -TGS REP going back and forth between the client browser and the Domain Controller. Many for each http request. This was the root of the problem, causing big latency. Problem analysis and experimentation further revealed the issue went away if Kerberos was configured for constrained delegation instead of unconstrained delegation. This was acknowledged by Apple as a bug and a fix is currently in beta.

To get to the above observations I put separate requests into a sequence in my mind: the anonymous request and the follow-up Kerberos authenticated request to the page. Such a sequence can actually be handled and presented by the tool if I only know the logic of the sequence by using a very nice MMA feature, the Pattern Match Viewer. I created a simple pattern via New Viewer and selecting Pattern Match in the dropdown.  I used the following settings for the pattern.  As a result requests going to the same URL with the same HTTP method are joined in a sequence.

Now that organized things for me and also included the overall timeline that the sequences fit into:

There were 80+ requests and they have now been boiled down to 40 sequences that I can drill further into. In more complex scenarios the pattern matching logic can be edited in code as well opening up for extensibility by creating more complex patterns.

I think the idea and the ability to apply patterns to big ammounts of data (from various sources) is exactly what is needed and MMA is a welcome solution in the right direction. Even for my little task the features for analysing and organizing the data was very useful.