We've had a few cases come through over the past few months regarding slow performance against Office Online from an EWS service application.  Several of them have come down to a very simple .Net setting that isn't necessarily obvious.  In fact, I first hit the issue myself when creating a streaming notification sample application, and it stumped me for a fair while.

EWS is a web service, which means that all the connections are HTTP/S.  HTTP connections in .Net applications are managed by a ServicePoint object.  ServicePoint objects are in turn managed by the ServicePointManager object. By default, the maximum number of concurrent HTTP connections that are allowed by a ServicePoint object is two - and this is something that will affect an EWS application if you are creating multiple connections.  What you'll find is that after the first couple of connections, requests suddenly take a very long time to return (if at all) - by very long time, this can be minutes.

The solution, fortunately, is quite simple (as is the case most of the time once the actual problem is identified...).  The number of concurrent connections a ServicePoint object will allow can be increased by setting the DefaultConnectionLimit property.  Once set, this will apply to any new ServicePoint objects that are created - so it is best to set this as soon as your application starts.

Due to the number of cases regarding EWS performance, I also wrote a benchmarking application (and note that none of the cases were actually due to performance issues in Office Online - they were all traced to client-side problems) which can be used to test if the issue is likely to be environment or code related.  Full source (Visual Studio 2013, .Net 4.5)  is attached to this post, and the screenshot below shows it in action.  The code also shows how multithreading and impersonation can be used.  The statistics shown are the actual results from a test against Office Online.