A while back I published a blog article that showed the performance improvements that can be achieved in CRM 2011 by enabling WCF compression. This specifically applies to the traffic generated by the CRM Outlook client or other applications using the CRM web services. The improvements mentioned back then also hold true for CRM 2013.
In my previous article I explained that IIS compresses many content types, but by default it will not compress WCF responses which have a mimeType of ‘application/soap+xml;charset=utf-8’. Since the WCF traffic is not compressed you may notice there is increased network traffic or performance is degraded when the CRM Outlook clients are brought online. These type of issues can be mitigated by enabling WCF compression and/or using SSL encryption for CRM. The biggest improvement is achieved by using both WCF Compression and SSL as I show in the following charts.
Below are network statistics from launching the CRM 2013 Outlook client and navigating some default views. I first captured a baseline and then repeated the steps using compression, SSL, and then a combination of SSL and compression.
If using just WCF compression there may be up to a 28% reduction in response size from the server. There should be very little change in the request size as compression only affects server to client traffic.
When only SSL is enabled both the request and response size over the network is reduced by up to 45%. That brings up the question, “How can enabling SSL help reduce network traffic”?
By just comparing the traffic side by side in Fiddler you can see that WCF will implement its own encryption if SSL is not present. This results in a large amount of encryption data to be passed with the WCF request and response.
When SSL is introduced WCF no longer implements its own encryption and that extra encryption baggage is no longer passed to/from the server.
Now when both Compression and SSL are enabled there is up to a 94% reduction in the response size.
We can see that the total reduction of network traffic is substantial, but if you are working on a local network the difference in response time is hardly noticeable. The biggest performance benefit is for the remote users that are on slower network connection where latency is present. To show this scenario I emulated network latency of 77ms and transfer rates of 192KB/sec. These are performance numbers I often see with real customers working outside the office.
For a user with this type of network speeds it can take close to 16 seconds to fully load the Outlook client and around 5.5 seconds to load a view. If we implement SSL and WCF compression these response times can drop by 44%.
This is great data, but the next question is how will this affect server performance now that it has to compress and encrypt the traffic?
In most cases the CRM Servers will have plenty of processing power so the overhead of compression and SSL is hardly noticeable. IIS has safeguards built-in that it will automatically stop compression if CPU ever spikes above 90% and will stay off until CPU drops below 50%. If server performance is a concern then load testing is the best way to fully understand the impact of these settings in your environment.
How to Enable WCF compression.
You may enable compression either by using a command line or by manually modifying the ApplicationHost.config file on the CRM Server. Below are the steps for each process.
Note: You may notice an increase in CPU utilization with compression enabled so be sure to monitor CPU accordingly.
Enable compression using a command line.
a. Open the Command Prompt on the CRM Server.
b. Run the following command:
%SYSTEMROOT%\system32\inetsrv\appcmd.exe set config -section:system.webServer/httpCompression /+"dynamicTypes.[mimeType=’application/soap%u002bxml; charset=utf-8′,enabled=’true’]" /commit:apphost
c. Reset IIS for the setting to take effect.
Enable compression by manually updating the ApplicationHost.Config
a. On the CRM Server Navigate to: C:\Windows\System32\Inetsrv\Config\applicationHost.config and open it with notepad.
b. Search for the Section: “<dynamicTypes>” and in that section you should fine an entry that looks like this:
c., Below that, add the following line:
<add mimeType="application/soap+xml; charset=utf-8" enabled="true" />
d. Save the file and reset IIS for the setting to take effect.
Note: For additional information about configuring HTTP compression, on TechNet, see the article Configuring HTTP Compression in IIS 7 at: http://technet.microsoft.com/en-us/library/cc771003(WS.10).aspx
Microsoft Dynamics CRM
Premier Field Engineer