Priority-Based Throttling is starting on version 10.0.19. This has caused some concern for users who are heavily dependent on OData or Custom Web Service calls from third party software, i.e. ISVs, EDI, Integrations, web portals, custom web apps. Everything here is up to date as of July of 2021. I expect some changes to come over the next months and years which may invalidate some of what is discussed here. I oversaw extensive testing, analyzed a month of LCS logs, and held some insightful conversations with Microsoft so there are a few gems in here for everyone.
Ξ Why Throttle Requests? Throttling is a common way SaaS vendors prevent spikes in demand which can cause degradation of the user experience, or in the worst case server crash (denial of service). Microsoft is responsible for providing an environment with a certain level of responsiveness, and therefore they must throttle lower-priority requests to ensure that the best possible user experience.
Ξ What is throttled? In general, any third-party OData (F&O Data Entity) or Custom Service requests will be throttled. Current exclusions/exemptions to throttling include:
Check Microsoft Docs for updates to the exclusion list in the future.
Ξ When does throttling kick in? To accomplish the goal of reliable performance, F&O does not need to start throttling until the environment is under ‘heavy load.’ The F&O load balancer will look at the currently used CPU and memory to determine when to begin throttling for each priority tier. The thresholds will vary from environment to environment, and this is an area that Microsoft wants to keep to their discretion. For illustrative purposes only lets say the following thresholds are established.
I have found that currently F&O is consistently asking for the request to wait for 60 seconds before sending the request again. You could retry after 10 seconds, but there isn’t a guarantee that it would work. You could also try after five minutes, and the same is true.
Ξ Configuring Priorities Priorities should be configured in F&O to ensure that near-real time calls are given the priority over less critical requests. If you leave something unconfigured, or forget to have a record for a particular user or client ID, it will default to high.
System administration > Setup > Throttling priority mapping
Suggestions
Tips and Notes
On versions prior to 10.0.19, I found the “Requests Throttled” report to be more accurate that the “All Throttling Events” query in LCS when looking for what requests could be subject to throttling when the environment is upgraded to 10.0.19+.
Caveat: When the system is utilized above the threshold, let’s say 70%, then it stops replying to requests based on the priority. In that situation if the environment stays above 70% utilization for an hour, NONE of the low-priority requests will be processed during that time. I see this as a possible area of improvement, as throttling could work more like airport queues, with dedicated processing power for all priorities so that low priority requests would be processed during heavy load, although at a reduced rate when compared to high-priority requests. Now, before this sends up an alarm, this would be very atypical and rare.
If the LCS log analysis reveals that considerable requests may be throttled:
Good luck with your testing! Please leave a comment or tweet me with feedback or your experiences.
Dag III
The post Throttling on Dynamics 365 Finance & Operations (Supply Chain Management) Starting 10.0.19 appeared first on Dag Calafell, III.
Original Post https://calafell.me/throttling-on-dynamics-365-finance-operations-supply-chain-management-starting-10-0-19/