Silverlight - gzip compression for your Domain and Duplex service(s)

/

I've been pretty unhappy with the data that's been thrown back and forth between a RIA DomainService and the Silverlight client.  I feel it's too big, too heavy.  When everything is running on localhost, you can't feel this.  But the moment you put everything onto an external staging server (or the production) - it's suddenly painfully obvious that perhaps some of the services are just way too chatty, that's a post for another day.

While thinking about this on my way to the car after work, I suddenly remembered that I still haven't turned on gzip compression for the production server.  A grin comes to my face, cause I know this would be an easy win.

 

Profile

First, measure your existing service calls.  You can do this easily with Fiddler 2, which lets you watch all HTTP traffic between your browser (where the Silverlight client sits), and the server, where the Domain and Duplex services are busily responding.

image

Figure: Domain Service request call

image

Figure: Duplex service call

 

Enable GZIP compression on Server

Enabling GZIP compression on the server, in 3 easy steps

1. The server has to know explicitly you want to compress these new content types.

Open C:\Windows\System32\inetsrv\config\applicationHost.config  as administrator

Modify the dynamic compression section, add our two new content types

Note; the exact mimetype depends on your service binding, and whether you choose to use text encoding.  Check Fiddler data if you aren't sure.

 

image

 

2. Enable dynamic compression via IIS on your web application

image

 

3. Recycle the AppPool (or the more catastrophic IISRESET, if you prefer that)

 

Result - test again

Refresh your Silverlight page, and let's see the new data

image

Figure: compressed domain service

 

image

Figure: compressed duplex service

 

Conclusion

I've picked a service call that's only returning 1 row of data, and it's shrunk the data size by 60%.  Over large chunks of data, I expect the compression to be significantly higher.

Smaller messages means less time for the browser to receive the response message, and since browsers already take care of compression and encoding, Silverlight doesn't even need to know that the message has arrived compressed.

Result is a small speed improvement over external sites with only a few simple steps Smile