Performance Best Practices
[Applies to: Microsoft Dynamics CRM 4.0]
Find the latest SDK documentation: CRM 2015 SDK
The following best practices will help you write code that performs better.
Use Multiple Threads
Add threading support to your application to break the work up across multiple CPUs. This assumes that you are running the code on a multi-processor system.
For more information, see the NET Framework Developer's Guide article on Managed Threading at msdn2.microsoft.com/en-us/library/3e8s7xdd.aspx.
Use NTLM Authentication
For more information, see Designing Distributed Applications with Visual Studio .NET, IIS Authentication at msdn.microsoft.com/library/en-us/vsent7/html/vxconIISAuthentication.asp.
Use Connection Sharing
This is also called unsafe connection sharing. Connection sharing is safe when you are running an application as a single user, for example, if you write a program to do bulk import for a custom entity. If your application will have multiple users, you can create a separate application pool for the program to run in to increase the measure of safety when using connection sharing.
// Create the service. CrmService _localService = new CrmService(); _localService.Credentials = _crmService.Credentials; _localService.Url = _crmService.Url; // Turn on unsafe connection sharing. _localService.UnsafeAuthenticatedConnectionSharing = true; // For a program with multiple users, create a new application pool // rather than using the default. _localService.ConnectionGroupName = "default";
For more information, see the documentation for the .NET Framework Class Library HttpWebRequest.UnsafeAuthenticatedConnectionSharing property at msdn.microsoft.com/library/en-us/cpref/html/frlrfSystemNetHttpWebRequestClassUnsafeAuthenticatedConnectionSharingTopic.asp.
Use Common Methods
The CrmService common methods are faster than using the CrmService.Execute method with the corresponding message. The following table lists these methods and messages.
|Create Method||Create Message|
|Delete Method||Delete Message|
|Update Method||Update Message|
|Retrieve Method||Retrieve Message|
|RetrieveMultiple Method||RetrieveMultiple Message|
Use Strong Types
The DynamicEntity class is useful for when your code needs to work on entities and attributes that are not known at the time the code is written. However, this flexibility comes at a price. If your entities are already defined at code time, you should use the strong types provided for you in the WSDL.
If possible, disable all registered plug-ins before running your application.
Write Plug-ins That Execute Faster
Always write a plug-in that takes the least amount of time to perform its intended task. For example, the Execute message is processed frequently in Microsoft Dynamics CRM. If you register a plug-in on that message, your plug-in could have a significant performance impact on the system because it will execute every time the Execute message is processed.
Consider the scenario where a plug-in is registered on the Execute message in order to be executed whenever the Microsoft Dynamics CRM Web application retrieves data to populate a grid view. The plug-in should be written to first check if ExecuteFetchRequest, a request that the Web application uses, is being processed. If that request is not being processed, the plug-in should return. The way to determine if that specific request is being processed is to examine the InputParameters property bag to see if it contains a property named FetchXml, which is an instance property of ExecuteFetchRequest.
Limit Data Retrieved
When using the methods that retrieve data from the server, only retrieve the minimum amount of data needed by your application. This is done by specifying the column set, which is the set of entity attributes to retrieve.
When using the Retrieve method, use the columnSet parameter to specify the attributes you need.
Limit Operations that Cascade to Related Entities
When using the Update method, do not set the ownerid attribute on an entity instance unless the owner has actually changed. Setting this attribute often requires changes to cascade to related entities, increasing the amount of time required for the update operation. For more information, see Cascading Rules.
Adjust Proxy Settings on the Client (On-Premise)
A proxy server sits between a client application, such as a Web browser, and the actual target server. When a computer is in a LAN, it can use a proxy server to connect to the Internet. In this case, the proxy server is combined with, or is a part of, the gateway server and firewall server. The proxy can cache Web requests and serve multiple client requests with its cached data. If the requested data is not present in the proxy server's cache, it forwards the request to the actual server by using its own IP address. Here, the proxy server acts on behalf of the client computer.
Although a proxy server can act as a cache server and help to load a Web page faster, it can sometimes decrease performance if used incorrectly. Frequently, people avoid manual proxy configuration and use automatic proxy configuration. This helps in load balancing the proxy servers, but depending on the complexity of the configuration script, a significant delay can be experienced when you use automatic proxy configuration.
When Microsoft Dynamics CRM 4.0 server is installed, you can completely bypass the proxy server to achieve greater throughput. The server offers a local Web address that requires no proxy to be reached. You can select Bypass proxy server for local addresses and provide the fully qualified domain name of the Microsoft Dynamics CRM server in the exceptions list. This gives better throughput when records are created by using the Microsoft Dynamics CRM SDK.
For more information, see "Take the Burden Off Users with Automatic Configuration in .NET" at msdn.microsoft.com/msdnmag/issues/05/08/AutomaticProxyDetection/default.aspx.