Tips for faster and better performance on Microsoft Dynamics CRM 4.0
There are many different factors that affect performance when implementing a CRM system; the hardware, network, infrastructure, business processes, system configuration, ect. Finding those bottlenecks and identifying their actual causes can take a lot of time and might not be an easy task.
In this post, I’ll show what to look for based on my experience from global and local CRM implementations.
Latency
When deploying MS CRM in a WAN environment, a major consideration is the distance between the server(s) and the clients in the solution. As the distance increases, the delay, or latency, associated with each round trip can also increase.
For example, for a connection between a user located in London and a server located in Stockholm, the associated round trip time is 15ms, but were the user located in China, the connection to the sever in Stockholm would require approximately 300ms.
Because downloading a CRM page can consist of multiple roundtrips, the latency associated with a particular connection can directly affect CRM performance. For the example above, a CRM page required 10 round trips to load, the user in London would see the page in less than 0.150 seconds (ten times 15ms), while the user in China would have to wait for 3 seconds (10 times 300ms).
As a result, the fewer the round trips between the client and the server, the better CRM performs.
What is the best way to account for latency during solution design? My experience indicates that during the early phases of a project, it is critical to identify any potential areas of the solution that that might require extra roundtrips. Then, if possible, limit or build smarter functionality for those areas. Try only to render what’s in context or what the user needs at the moment. Perhaps have a verification triggered manually rather than during each onload of the CRM form?
Question every requirement and think about how that specific function might have impact on performance. Using third party tools such as WAN accelerators has been successfully implemented as noted in the Optimizing and Maintaining Microsoft Dynamics CRM 4.0 documentation. The use of caching on the client is also a trick and make sure all static files are marked correctly in the IIS. Crunching and removal of white spaces improve performance in JScript added to forms. There are multiple tools out there to be used and could be part of the build process. Usage of the offline client might also improve performance if the client is used in offline mode and later background synchronized back to the server.
I hope that IE 8 will support more ports open during the load of pages. Currently IE can only have 2 ports open per domain. Microsoft Dynamics CRM 4.0 does not support the possibility split files on separated domain to have IE open more ports and then load files more in parallel.
Adding IIS fronts closer to end-users but still having a centralized SQL server does not show any better performance from my experience, rather surprising the performance was worse using that approach. What’s doing great results are adding custom indexes to DB and I would recommend using the different DBA tools available and monitor where to add new indexes.
Centralized vs. De-centralized Topology
When deploying MS CRM in a WAN environment, you can opt for a centralized or decentralized topology. A centralized approach Using a de-centralized (federated) The two types of typology are described and compared in the following table:
|
Topology |
Description |
Pros |
Cons |
|
Centralized |
CRM servers consolidated in a central location |
A fully centralized infrastructure is easier to manage and maintain; consolidating resources carries lower TCO and procurement costs. |
Query performance suffers from long distance access; retrieving data from remote locations significantly impacts processing speed and data latency |
|
De-centralized |
Local CRM servers are distributed around the globe |
Users benefit from considerably faster query and reporting; local adoption of the solution at management level will typically be easier |
Considerably higher procurement, operations, and maintenance costs; much greater difficulty in maintaining alignment of local solutions to a standard. Data volumes transferred to local implementations have high, concentrated impact on the network |
What about hardware then? When planning for hardware selection, I consider the following points.
- Number of transactions per hour – Total average number on key entities used to support business process.
- Number of concurrent users – In global implementation user amount might be high but not all working in the system at the same time. Take advantage of the time zones. Don’t forget that outlook client talks to the servers regularly depending how you setup your synchronization.
- Amount of customizations – Workflows, plug-ins do we need to have dedicated SDK servers? In CRM 4.0 you can separate as shown in the following table:
|
Services |
CRM Application Server |
CRM Platform Server |
|
Web Application Server |
ü |
|
|
Help Content Service |
ü |
|
|
SDK Service |
|
ü |
|
Asynchronous Service |
|
ü |
|
Discovery Service |
|
ü |
|
Deployment Service |
|
ü |
- Availability and failover – Clustering on SQL, farm on application and web fronts. Don’t forget Reporting Server! The more you secure uptime on your system -the more servers but better sleep and happier users
- Central vs de-centralized – De centralized requires more hardware as noted above
Figure 1: Sample of suggested server topology, this is just one example, and depending on the scenario, another topology might work better. Customer environments are unique and each implementation requires analysis and consideration of the variables in specific scenario.
