Performance

The following best practices will help you write better performing code using the Microsoft CRM 3.0 SDK. For more information about improving the performance of Microsoft CRM 3.0, see Optimizing the Performance of Microsoft Dynamics CRM 3.0 White Paper, located at www.microsoft.com/downloads/details.aspx?FamilyId=6B32E0B3-5520-48A7-B3CD-D8477D084821\&displaylang=en.

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 multiprocessor system.

For more information, see Managed Threading in the .NET Framework Developer's Guide, located at msdn2.microsoft.com/en-us/library/3e8s7xdd.aspx.

Use Integrated Windows authentication

For more information about Integrated Windows authentication (formerly known as NTLM authentication), see IIS Authentication, located at msdn2.microsoft.com/en-us/library/aa292114(VS.71).aspx.

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.

Example

// 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 HttpWebRequest.UnsafeAuthenticatedConnectionSharing Property in the MSDN library, located at msdn2.microsoft.com/en-us/library/system.net.httpwebrequest.unsafeauthenticatedconnectionsharing.aspx.

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.

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 Web Services Description Language (WSDL). For more information, see the SDK topic Using Dynamic Entities to Access Entities at Runtime.

Disable callouts

If possible, disable all registered callouts and workflows before running your application.

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 the QueryExpression class to specify the query criteria, use the QueryBase.ColumnSet field. The following messages use QueryExpression:

·RetrieveByGroupResource

·RetrieveByResourceResourceGroup

·RetrieveByResourcesService

·RetrieveMultiple

·RetrieveParentGroupsResourceGroup

·RetrieveSubGroupsResourceGroup

·Rollup

Limit operations that cascade to related entities

When using Update, don't 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.

© 2007 Microsoft Corporation. All rights reserved.