HTTP Compression

star870126

HTTP Compression - .NET vs IIS/ISAPI


Many major sites such as Google, Amazon and eBay all have one thing in common - they use HTTP Compression extensively both to speed up page download times and save on bandwidth.

If you are using IIS and want to benefit from web compression then you have a number of options available. You can use the IIS built-in compression filter (available in IIS 5.0 and improved in IIS 6.0) or any one of several other commercial ISAPI filters:

http://www.pipeboost.com/
http://www.httpzip.com/
http://www.xcache.com/

If you are using ASP.NET then you can of course use our ASPAccelerator.NET component or HttpCompress.

As you can guess, they are all pretty similar in that fundamentally they do the same thing (reduce page output size using HTTP compression) but there are significant differences depending on whether you go for a .NET approach or an ISAPI one. So which one should you go for and why?

ISAPI filters work at the IIS level which means that they can act on any request made to the web server. An ISAPI compression filter can typically compress static site content such as HTML files as well as dynamic application output. A .NET module on the other hand can only process requests that are handled by the ASP.NET engine.

Installing an ISAPI filter requires administrator permissions and console access to the web-server. Enabling HTTP Compression in IIS is normally something that the server administrator would do and requires changes to the IIS MetaBase. Adding a .NET module is much easier and can still be done by the administrator at the server-level by changing the machine.config file but also by the application developer / web author by including the assembly and changing the web.config file.

This is perhaps the biggest difference between the two - HTTP Compression deployment and configuration is part of your application so is usable on shared hosting without any admin/console access and configuration can be made to suit your app (eg. different compression levels may be appropriate for different pages).

This makes the .NET solutions much more appropriate for application developers who want to build HTTP Compression into their application whereas the IIS/ISAPI approach is targeted more towards server administrators.

In terms of performance there are a lot of factors involved. Our own .NET solution was significantly faster than the IIS 5.0 ISAPI filter but since Microsoft put a lot of work into optimising the compression filter for IIS 6.0 the difference is now negligable. For many situations the .NET solution can still be faster though.

Because ASPAccelerator.NET is a .NET Module and runs as part of your ASP.NET application it is aware of ASP.NET Output Caching and so can avoid re-compressing already compressed pages which can make a big difference to CPU usage on a busy server. IIS doesn't know whether the page output has just been generated or is the same cached version that has been served out 1,000 times before - it re-compresses the dynamic output again each time.

If you are interested in HTTP Compression then you are likely to be interested in performance and are probably already using or looking at ASP.NET Output Caching. If so, I'd recommend comparing the compression performance of .NET and ISAPI solutions with Output Caching is used.　　One other thing worth mentioning is configuration. Whether a particular request can be compressed or not depends on features of the request. While IIS allows some configuration the level of control available is not as powerful as the rules-engine that we use for ASPAccelerator.NET which allows complete control over the content negotiation process.
　　Finally, while the ISAPI solutions can compress output of web-services (if configured correctly) the client cannot by default uncompress these. We provide additional helper classes that enables HTTP Compression support to web-service clients. This works at the protocol level so the same classes can be used whatever compression solution is being used on the server.
　　In addition, we also include WSE 2.0 filters to add compression to SOAP packets. This enables compression of SOAP requests going both from and to the server and would, for instance, allow DIME attachments being uploaded to the server to be compressed (the WSE filter needs to be added to the client and the server and is a proprietary extension).
　　Whatever the traffic on your site, or the solution that suits you best, I'd recommend you giving HTTP Compression a try - it provides real ROI (if your bandwidth bill is large enough or you are on the limit with your hosting allowance) and avoids having slow downloads that some users may not be willing to wait for.