Exchange throttling is your friend… well, more like a police officer.
Here is one way to think of Exchange throttling:
- Exchange is the freeway.
- Applications accessing Exchange are the drivers on the freeway.
- Exchange Throttling is the COP who is there to enforce the rules if you don’t behave.
- The Exchange Administrator of the servers is the governing power which establishes the throttling limits (laws) which must be obeyed.
Sound odd? Well, its a very close analogy to the real world of Exchange throttling. See, many developers and admins have a negative view on throttling on Exchange servers and see it as an obstacle. This is very negative and wrongful thinking. Throttling prevents programs from dominating a server, causing performance issues and preventing connectivity.
One way to think of Exchange and throttling is as follows… Exchange is like a freeway with many vehicles on it. A vehicle in this case is an application talking to Exchange and the underlying code of that application is the driver. On a freeway there are rules drivers must follow such as don’t speed, stay in your own lane, etc. – i.e. the drive must self-throttle their actions in order that they don’t cause problems. In this scenario the way to look at Exchange throttling is that it’s the police officer who will enforce the rules of throttling when a program does not self-throttle. So, it’s up to the application to self-throttle and be able to either work within Exchange’s default limits at a minimal or to be able to adjust to new limits set by an Exchange administrator – the same as a drive must know the laws and throttle their actions within those laws.
The past few versions of Exchange have made great advancements in throttling. In older versions there was not much in the way of Exchange throttling and there was an expectation that programs would just be nice and not cause issues… Well that is like having a freeway with no driving laws or rules. Those older versions of Exchange only had some extremely limited throttling built in and it was basically like only having guard rails and nothing else in the freeway scenario. So, imagine the next time you’re driving on the freeway what would happen if everyone got to drive however they wanted… yeah. Because of problems caused by applications doing their own thing and causing severe performance issues and even taking down servers there needed to be a way to reign in the anarchy and bring things to a more civilized state – i.e. advanced Exchange throttling was needed to police the servers to prevent badly behaving programs from causing issues.
So, when you write code against Exchange you should be aware of the throttling limits and their defaults. The code you write either needs to work within the limits and if it might exceed throttling limits then it needs to be able to self-throttle within the limits set on the server – default of otherwise set by an admin.
Here are some links for review:
Best Practices - Throttling
https://blogs.msdn.microsoft.com/webdav_101/2015/05/03/best-practices-ews-throttling/
EWS throttling in Exchange (EWS Managed API | Exchange Online | Exchange Server 2013 | Office 365)
https://msdn.microsoft.com/en-us/library/office/jj945066(v=exchg.150).aspx
New-ThrottlingPolicy
https://technet.microsoft.com/en-us/library/dd351045(v=exchg.150).aspx
Understanding Client Throttling Policies (Exchange Server 2010 SP3, Exchange Server 2010 SP2)
https://technet.microsoft.com/en-us/library/dd297964(v=exchg.141).aspx