While creating a REST component to execute some operations against an exchange instance, I noticed some performance issue. Surprisingly the unit/integration-test suite was a lot faster when Fiddler was active.
This seems to be some kind of default problem when developing .NET application as Telerik even added its own page for this scenario.
However, if none of those apply to your situation – as it was the case for me – you should read on to get an idea on how you can debug this further (and you even might have the same problem!).
In fact, if you have such a problem you will need to go down the protocol line and use tools like “Microsoft Network Monitor” (now replaced with “Microsoft Message Analyzer”) or “Wireshark” to further diagnose the problem.
In theory those tools are even able to decrypt SSL traffic (in a world where more and more connections are secured!). But all tools either failed to properly decrypt the traffic or even crashed completely. Maybe I just failed to configure them properly. I therefore temporarily disabled SSL on the Exchange server (a test instance of course) to further diagnose the problem.
After finally comparing the outputs with Fiddler running and not running you could see that a lot more requests were made when it was not running. And you could see that those were obviously NTLM Auth (Integrated Security) messages.
But why doesn’t .NET reuse the connection even when Keep-Alive is set properly?
Now with this new information it was quite easy to find the relevant information on stackoverflow.
There is an additional well-hidden property in the .NET framework, called ‘UnsafeAuthenticatedConnectionSharing’ to control this behavior. It’s actually a security feature to not accidentally re-use connections with a user when the connection is already authenticated for a different user.
In my case this wasn’t a problem as I only used a single service account for the connection. In Fiddler it would work as expected as they seem to manage the connection pool by themselves. After setting the property everything worked in the application as it did with Fiddler. However, you should be careful. If your application needs to authenticate multiple users you might want to use the ‘ConnectionGroupName’ property in combination with the ‘UnsafeAuthenticatedConnectionSharing’ to seperate the connections.
Note: For my service I patched the exchange managed EWS API to set the ‘UnsafeAuthenticatedConnectionSharing’ property as soon as the ‘ConnectionGroupName’ is used. Let us now if you are interested in the patch.
If you are afraid of the security implications of these changes let us know in the comments (make sure to anonymize your concern) or contact us directly.