|
|
17.01.2009, 00:05
|
#1 |
|
Участник
|
Microsoft Dynamics CRM Team Blog: Tips for faster and better performance on Microsoft Dynamics CRM 4.0
Источник: http://blogs.msdn.com/crm/archive/20...s-crm-4-0.aspx
============== 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: table.msotablegrid {border:solid black 1.0pt; font-size:11.0pt; font-family:"Calibri","sans-serif"; } p.msonormal {margin-top:0in; margin-right:0in; margin-bottom:10.0pt; margin-left:0in; line-height:115%; font-size:11.0pt; font-family:"Calibri","sans-serif"; } 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 Hardware Planning What about hardware then? When planning for hardware selection, I consider the following points.
CRM Application Server CRM Platform Server Web Application Server ü Help Content Service ü SDK Service ü Asynchronous Service ü Discovery Service ü Deployment Service ü
 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. Additional Information
Jonas Deibe Источник: http://blogs.msdn.com/crm/archive/20...s-crm-4-0.aspx
__________________
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору. |
|
|
Комбинированный вид
