Allgemein Für Administratoren Für Architekten Für Entwickler Für Projektleiter Für Tester News Produkte Publikationen
Matthias Dittrich

Matthias Dittrich

Performance issues with Exchange EWS API

Dienstag, 10. Mai 2016

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?

2016-05-09 09_16_37_Initial_cut

Screenshot of captured packages with ‚Microsoft Network Monitor‘ when Fiddler is not active. You can see on the left that many connections are established and closed. On the right in the frame summary you can see the authentication and a single request. Every connection on the left looks like this, which clearly shows that the connection is not kept alive.

2016-05-09 09_16_37_Fiddler_cut

Screenshot of captured packages with ‚Microsoft Network Monitor‘ when Fiddler is active. You can see on the left Fiddler only established and closed a single connection. On the right in the frame summary you can see the authentication followed by additional requests. Those additional requests don’t have the overhead of establishing an authenticated connection.


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.

2016-05-09 09_16_37_EwsCode

Code-change in the EWS Managed API.

2016-05-09 09_16_37_AfterChange

Finally our application behaves like Fiddler above. You can see that now our Test-Runner only establishes a single connection (left) and uses it for all its requests (right).

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.

Verwandte Artikel:

Benötigen Sie Unterstützung bei der Software-Entwicklung und Architektur von .NET basierten Lösungen oder bei Einführung und Anpassung von Visual Studio / Microsoft Test Manager / Team Foundation Server?

Wir stehen Ihnen unter info(at) gerne zur Verfügung.

Tags: , , , , ,

Hinterlasse eine Antwort