Performance Best Practices

banner art

[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

Use NTLM Authentication

For more information, see Designing Distributed Applications with Visual Studio .NET, IIS Authentication at

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

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.

Method Message
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.

Disable Plug-ins

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.

When using the RetrieveMultiple method, specify the attributes to retrieve in the query using the QueryBase.ColumnSet field.

When using any message that uses a QueryExpression to specify the query criteria, use the QueryBase.ColumnSet property. The following messages contain a QueryExpression.


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

See Also

Other Resources

© 2010 Microsoft Corporation. All rights reserved.