Timeouts and Platform constraints with Dynamics CRM

The Dynamics CRM platform has number of constraints (which I used to treat as errors) imposed to prevent any one action to impact the rest of the system. The question was whether the constraints can be lifted, but this is rarely a good approach when you consider the broader implications. As per the Scalability document provided by Microsoft, at the heart of these constraints is the idea that the Dynamics CRM platform is a transactional, multiuser application where quick response to user demand is the priority. It’s not intended to be a platform for long running or batch processing. It is possible to drive a series of short requests to Dynamics CRM but Dynamics CRM isn’t designed to handle batch processing. Equally, where there are activities running large iterative processing, Dynamics CRM isn’t designed to handle that iterative processing. In those scenarios, a separate service can be used to host the long running process, driving shorter transactional requests to Dynamics CRM itself. It is worth being aware of and understanding the platform constraints that do exist, so that you can allow for them in your application design. Also, if you do encounter these errors, you can understand why they are happening and what you can change to avoid them.

  • Plug-in timeouts
    • Plug-ins will time out after 2 minutes
    • Long running actions shouldn’t be performed in plug-ins. Protects the platform and the sandbox service and ultimately the user from poor user experience
  • SQL timeouts
    • Requests to SQL Server time out at 30 seconds to protect against long running requests
    • Provides protection within a particular organization and its private database
    • Also provides protection at a database server level against excessive use of shared resources such as processors/memory
  • Workflow limits
    • Operates under a Fair Usage policy
    • No specific hard limits, but balance resource across organizations
    • Where demand is low, an organization can take full advantage of available capacity, but where demand is high, resources and throughput is shared
  • Maximum concurrent connections
    • Maximum connection pool limit of 100; connections from web server connection pool in IIS to the database
    • Have never seen a scenario where this should be increased. If you hit this, it is an indication of an error in the system; look at why so many connections are blocking
    • With multiple web servers, each with 100 concurrent connections to the database of typical <10ms, this suggests a throughput of >10k db requests for each web server. This should not be required and would hit other challenges well before that
  • ExecuteMultiple
    • ExecuteMultiple is designed to assist with collections of messages being sent to Dynamics CRM from an external source
    • The processing of large groups of these requests can tie up vital resources in CRM at the expense of more response critical requests by users, therefore this is limited to 2 concurrent ExecuteMultiple requests per organization

A common misconception is that these limits are only applied in Dynamics CRM Online. This isn’t accurate as they are applied equally in an on-premises deployment of Dynamics CRM. In an on-premises deployment, there is more scope to configure and relax these constraints, which gives the impression of more throttling in Dynamics CRM Online.

However, as described earlier, hitting these constraints is an indication of behavior that affects other areas of your system, so investigating and addressing the root cause of the behavior is preferable to simply loosening the constraints, even in an on-premises deployment. In an on-premises deployment you’re still affecting your users with slower than necessary performance.