Best Practices - EWS Throttling
There are some developers and admins who don’t like it when their applications get throttled by Exchange. Some get pretty "excited". However it’s important to have the correct perspective and that is Exchange is throttling calls from an application because that application is failing to self-throttle. Applications and the developers of them need to take into account that Exchange has the failsafe of throttling to prevent an application from causing severe impact to Exchange’s performance. All applications really need to self-throttle.
In the past I would see nearly countless cases where customers had horrible performance issues which would brink Exchange to nearly a hang conditions. The servers would be under a crushing load by an application which was not self-throttling. I’ve seen this with applications written with EWS, MAPI, ActiveSync, CDO 1.21, ActiveSync, WebDAV and PowerShell. This used to be a major problem which many of our customer’s faced. So, changes had to be made to Exchange to introduce throttling which would prevent badly behaving applications from crushing servers. The reasons that the software vendors did not correct this type of behavior was often because they did not do scaled-up testing and in some cases they were only concerned about their application performance on the client end and not the impact it had on the server and other users (not joking on this point).
Again, Exchange side EWS throttling prevents applications from dominating the server. It’s best to keep throttling policies active and have your applications self-throttle. So, EWS throttling on the server is our friend.
It's important to understand throttling policies. Please note that throttling for Exchange is different in different versions of Exchange (it keeps evolving), so be sure to read-up on throttling for the version of Exchange your code is going against.:
EWS throttling in Exchange (EWS Managed API | Exchange Online | Exchange Server 2013 | Office 365)
Understanding Client Throttling Policies (Exchange Server 2010 SP3, Exchange Server 2010 SP2)
You can look for 2915 events in the Application Event log on your Exchange server to get details on why your application was throttled. Those events are recorded when Exchange throttles and should point the throttling policy used when your application is throttled. With Exchange Online / Exchange 2013 you should see information returned in the EWS which indicates the throttling policy encountered. Note that you will not be able to have access to the Application Even logs when going with Exchange Online, so you really need to log the details of failing response in order to help diagnose the cause of throttling.
A lot of people believe that if you set a throttling policy to null that it turns that off. Well… maybe sometimes, but not really. What it does is to cause the throttling to default to a hard coded value, which last I checked was not documented and which also might change with any service pack or rollup. So be aware of that.
In Exchange 2013 there is a thing called micro delay throttling. Exchange tries to detect applications which are sending EWS traffic which is creating a large performance hit and will inject delays in processing when it detects it so that other Exchange code can run. This prevents an application from dominating the server. A custom policy can be set on an application service account used by the application which can turn this off – HOWEVER, it’s critical that the application self-throttles. With Exchange Online custom throttling policies are very difficult to get and are custom policies are not allowed with non-dedicated Exchange servers.