Enable WCF Compression & SSL to Improve CRM 2013 Network Performance

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:
<add mimeType="application/x-javascript" enabled="true" />

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



Jeremy Morlock
Microsoft Dynamics CRM
Premier Field Engineer

Comments (10)

  1. Alex says:

    Is it possible to enable this on CRM Online?


  2. JMorlock says:

    Hi Alex, This is already in place on the CRM Online Servers. So it is only something that needs to be configured for OnPremise environments.

  3. Steve says:

    Hi, what do you use to measure bytes sent, bytes received and request time? Thanks for the article!

  4. JMorlock says:

    I use Fiddler to capture the traffic. Its a free download from http://Fiddler2.com

    When you capture the traffic you can click on each request and the data size and time stamps will show up under the statistics tab.

  5. BorisB says:

    Or use standard diagnostic tool

    http: // <yourCRMServerURL>/tools/diagnostics/diag.aspx

    to measure latency and bandwith.

  6. Paul says:

    This isnt working after an IIS reset I check the traffic with Fiddler and it shows as uncompressed.  I double checked the Config file because I used the CMD command to set it and it shows up correctly.  When using fiddler it says uncompressed and not using Gzip.  

  7. JMorlock says:

    Hi Paul,

    I have encountered situations where a Firewall or Network Load Balancer can prevent compression from working properly even though IIS is set up correctly. I've seen this happen with ISA, TMG, and F5 to name a few. It usually came down to some built-in cachingcompression features not being set properly to allow WCF compression.

    Depending on the network layout you could identify if this is the culprit by using a host file to point the client directly to the CRM web server and bypass the proxy or NLB. That would be one quick way to identify whether the network appliance is the issue before digging into its settings.



  8. Paul says:

    Thanks for the fast reply.  I am not using any firewall or NLB.  However, I am using ADFS for claims based Authentication with CRM.  Do I need to do something on the ADFS end, thanks for your help!

  9. WSDL Compression says:

    Hi Jeremy,

    Can we enable compression on Content-Type: text/xml; charset=UTF-8 to enable compression on WSDL


    We are also interested enabling compression on everything.

    By default */* is False, Can we turn that on to compress everything?

    <add mimeType="*/*" enabled="false" />



  10. CAMjkCq says:

    4431 202590I like this blog so much, saved to my bookmarks . 592077

Skip to main content