We recently completed an exercise, on behalf of a Customer, to improve the performance they were experiencing from Microsoft Dynamics CRM plug-ins. These plug-ins contained complex business logic and had been created using C#. We were able to make a number of recommendations.
Isolation Mode:
Microsoft Dynamics CRM supports the execution of plug-ins and custom workflow activities in an isolated environment, also known as a Sandbox. Whilst plug-ins running in this isolated environment are more secure, it does add a performance overhead. In addition, the Sandbox has a limited number of workers, and if these are all busy, the plug-in will error.
To change the isolation mode, set the ‘IsolationMode’ setting in the ‘RegisterFile.crmregister’ file to ‘None’ or ‘Sandbox’. You will need to be a Deployment Administrator to move plug-ins from the Sandbox.
Please note, if you are using Microsoft Dynamics CRM on-line, plug-ins have to run in Isolation Mode.
Filtering Attributes:
Preventing a plug-ins from firing when it is not required will also aid performance. As well as ensuring that a plug-in is only triggered for the Stage (e.g. pre-operation) and Message Type (e.g. update), you can also specify Filter Attributes. As the Microsoft Dynamics CRM user interface only includes the fields that have changed when it submits an update request, then the Filtering Attributes can be thought of as ‘only run this plugin when the value of a referenced field changes’.
Filtering attributes can only be set on certain message types, e.g. they can’t be used on create. Where available they should be used, unless there is a very good reason.
Filtering Attributes can be set in the ‘Create Plug-in’ dialog. By default all fields are ticked, and so we recommend changing this to only reference the required fields.
Synchronous or Asynchronous:
Careful consideration needs to be given to whether your plug-in runs synchronously or asynchronously.
As part of the plug-in transaction any required system jobs are created. This means that if the plugin is synchronous and system job creation is slow (due to a high volume of workflow processing), the speed at which a record is saved can be adversely affect.
In a particularly intensive example that we found, when saving a change to 250 records with an asynchronous plugin the time taken was under 60 seconds. However, when the plug0in was made synchronous it took 55 minutes! This was because as part of the plugin it created another record, and each of these in turn triggered an additional 10 asynchronous workflows (2,500 workflows).
Typically plug-ins should only be synchronous, if the user is immediately reliant on the result.