Microsoft CRM 2011 allows XRM services that use application/soap+xml content type.
When you install Microsoft CRM 2011 in an IFD / hosted environment, it is smart enough to automatically configure IIS gzip compression on the website.
What it does not do, is configure the
C:\Windows\System32\Inetsrv\Config\applicationHost.config
file to compress XRM calls out of the CRM database.
In a test we were performing for an update to our Microsoft CRM 2011 Portal technology, we found that retrieving a list of around 20,000 items returned a 19 MB data package without gzip dynamic compression. Not huge but pretty big! What amazed us was that after enabling dynamic compression on the XRM data, this reduced from 19 MB to 890 KB, a huge performance improvement!
We also noticed that the Microsoft Hosted CRM 2011 service already has this compression enabled, so we figured if it is good enough for them, then we should give it a shot.
How to Enable XRM gzip Compression in IIS
Navigate to: C:\Windows\System32\Inetsrv\Config\applicationHost.config
and open it in your favourite editor.
Search for the Section: “<httpCompression directory=”
And in that section you will probably find an entry that looks like this:
<add mimeType="application/x-javascript" enabled="true" />
Below that, add the following:
<add mimeType="application/soap+xml" enabled="true" />
So the file looks like this:
Note: We are making the assumption that you are on Windows 2008, and that CRM 2011 was successfully installed, and that this in turn enabled IIS compression on the Microsoft CRM website.
These steps should massively improve data access to CRM using XRM calls.
Nicely shared info…Thanks!!
No problem.
“We also noticed that the Microsoft Hosted CRM 2011 service already has this compression enabled” – the response content is not GZIP encoded when I connect to CRM 2011 Online (30 day trial) XRM services.
How strange that is. Thanks for sharing this additional information. The implication is that whoever setup their trial server did not bother or did not complete the say way that their production team did. I suspect if you find the correct person to talk to in MS, they would fix it in 5 minutes. But we all know that will never happen.
I have also noticed that there is a significant different in response content size between CrmService.asmx (1.5MB) and Organization.svc (6.6MB). Organization.svc contains a lot of bloat XML. I was testing using a simple fetch xml query that retrieve four fields from the contacts table. Both didn’t use GZIP encoding.
I’ve been using Fiddler to inspect the http response from CrmService.asmx and Organization.svc XRM service requests. I’ve just realised that Fiddler ‘Decode’ option was enabled, which automatically decompresses all http traffic, giving the user the impression that the response isn’t GZIP encoded. I’ve disabled Fiddler ‘Decode’ option and Organization.svc response IS being GZIP encoded when I reference CRM 2011 Online Trial. CrmService.asmx isn’t being GZIP encoded.
Would this have much of an impact on clients who are only accessing the CRM from an Internal Ethernet network? I’m guessing that the speed of transferring that uncompressed data over a LAN is not really noticeable, but the extra CPU load on the server to compress might be?
First up it only relates to service calls that are getting XRM data. It is not related to normal CRM use and dynamic compression that is turned on by default. Where the savings takes place is in the time it takes for the server to send a large bunch of data. The actual load is nothing for a LAN, but it still is taking about 5x longer than it needs to.
Pingback: Drastically Improving WCF Download Times with Gzip + SSL | Something to Read on the Train