WCF services that are hosted in IIS can take advantage of compression without making any special encoder changes. In Windows Server 2008 R2, IIS compression is actually turned on by default and WCF as of .Net 4.0 supports decompression by default. So if you've got a WCF web-hosted service on a W2K8R2 server using an HTTP transport, then you don't have to do anything to take advantage of compression. If your goal is to have compression on your services and you meet those criteria, then you can kick back now and don't even have to read the rest of this post.
For the rest of us though, there are many interesting details to consider. I figured a question and answer format would work best to explain the nuances.
Q: I'm using Silverlight. How can I take advantage of compression?
A: The good news is that you don't have to do much. Silverlight itself is not responsible for decompressing the messages from a service. The browser will do that for you. Since all requests are essentially going through the browser, the browser can stick in the Accept-Encoding header in the HTTP message. That signals the web server that the client can handle compressed messages and the web server can then decide to turn compression on or off.
Q: If compression is on by default in W2K8R2, how does that affect performance?
A: With IIS, compression is not just always on or off. IIS can choose to use compression based on a number of parameters. For instance, if the CPU usage on the web server is below a minimum threshold or above a maximum threshold, then compression will be turned off. To keep the response times from being too erratic, IIS only checks every 15 seconds or so (not sure on the exact number). So if you're running a performance test you might get some weird results. For instance, this is a 20 second test where the compression was on at first and the bottleneck was the CPU, so the network usage was low. Then IIS decided to turn off compression because the CPU usage was above the threshold and that sent the network usage to 100%.
Read more: Dustin Metzgar's blog
Posts
0 comments:
Post a Comment