Posts Tagged ‘compression’

Here’s a tip to get the better performance when sending xml to a WCF web service from Silverlight or WPF…

Never send or return xml as a string. Anytime you pass around a string data type as a parameter to your service or send back a string return value, the string will be XML encoded. Imagine, the following string:

<hello/> (8 bytes)

this is really sent around as:

&lt;hello/&gt; (14 bytes)

Something that should have taken only 8 bytes of your bandwidth, took almost double that. Now an extra 6 bytes isn’t bad, but you can see how it wouldn’t take long for your xml to quickly inflate the overall size of the request or response and at some point even have a noticable delay for the usability of your app.

Fortunately, the solution is simple! Use an System.Linq.Xml.XElement object instead. By doing so, WCF is smart enough to encode your xml right in the message envelope as pure xml. Furthermore, if you need to work with that xml on the receiving end, it’s already in an object type more suitable for most purposes than a String.

To demonstrate and prove what is happening, I wrote a test app that sent a test parameter to a service as a String, XElement and byte array. The test data being sent in all three cases was the xml: <test/>. Then I used fiddler2 web debugging proxy to see what was actually sent to the server. Check out below what I saw:

Sending a String:


Sending a byte array:


Sending an XElement:

<s:Body><DoWorkXElement><param1><test /></param1></DoWorkXElement></s:Body>

XElement wins! 🙂 And just to be sure, I also confirmed that responses for the three data types produced identical results.


A note about compression

Compression does not completely remove the benefit of sending as XElement. Besides the fact that server compression only works on responses, it doesn’t eliminate the benefit from sending xml without encoding. This was surprising to me. I thought that compressing my responses on the server would find common xml encoding phrases like “&lt;” and “&gt;” and find a way to turn them into single bytes using a mapping technique and make an xml encoded and non-xml encoded response virtually identical in size when compressed. To test my assumption, I ran a test where I took a big xml file, and added it and an encoded version of it in a zip file. Here was my result:

encoded and decoded compression results

Acording Although encoded xml can be compressed at a slightly higher compression ratio, it was not as dramatic as I thought and suggests and the final compressed sizes show that although compression on the server helps reduce the size of your response a great deal, xml encoded strings will still be larger than necessary. Check out my previous blog post to find out more about opimizing responses by turning on server compression.


Read Full Post »

Keep your Silverlight app running fast by compressing your service responses. Imagine you’re downloading 1MB worth of text. Compressed, that same text can usually be reduced to under 200K. This reduction can be significant enough to be noticable to even clients on good internet connections and over time will save you money on bandwidth usage.

Fortunately, there’s NO need to find a 3rd party zip component or to try to do it yourself. IIS has everything all built right in, you just need to enable it.

The way it works is, the browser sends up an http header of “Accept-Encoding” with gzip and/or deflate as the value with each request to your WCF service. As long as IIS is configured correctly, the server will automatically compress the response from the service and the client will automatically decompress it before your code enters the picture. Not a single line of code is required on our part to take full advantage of this built in compression feature that works across most major browsers.

To set up IIS6 to participate you need to (sorry, haven’t tried this on IIS7):

1) In the IIS console, right click on “Web Sites”, choose properties, select the Services tab and check “Compress application files”


2) Also in the IIS console, go to the Web Service Extensions folder and click the “Add a new Web service extension” link. In the dialog that appears, enter a name for the extension. I named mine “gzip”. Next, enter the path of the dll capable of zipping the responses (c:\windows\system32\inetsrv\gzip.dll), and check “Set extension status to Allowed”.


3) Run the following command lines to update metabase.xml:

CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/GZIP/HcScriptFileExtensions “asp” “dll” “exe” “svc”
CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/DEFLATE/HcScriptFileExtensions “asp” “dll” “exe” “svc”
CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/GZIP/HcDynamicCompressionLevel 9
CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/DEFLATE/HcDynamicCompressionLevel 9

4) Restart IIS (you can right click on the computer name in the IIS console, choose All Tasks, and select “Restart IIS”). Not 100% sure this is necessary.

5) Wait. It took my server on Amazon EC2 approximately 3 minutes before the changes from step #2 flowed to the metabase.xml file. You can always go check by looking at the date modified of c:\windows\system32\inetsrv\metabase.xml

In the end, you can test that it’s working by going to PipeBoost and typing in the url of your .svc file. Also, when running your app, you can use a tool like fiddler2 to show you the data actually coming down to the client along with an indicator that it is compressed.

That’s it, don’t do a think to your Silverlight app but watch it instantenously start downloading data faster!

Read Full Post »