Published: 26 Aug 2011
By: Matt Perdeck

In this article, Matt Perdeck shows how to make your pages more compressible, sets out to settle religeous wars about CPU usage versus savings in page load times, and examines whether compression is the magic bullet.

Contents [hide]

The IIS compression Series

  • Part 1 Starting with this article, I'll show how to get the most out of the compression features built into IIS 7 and IIS 6. This first article focusses specifically on IIS 7.
  • Part 2 In this article, Matt Perdeck shows how to make the most out of IIS 6 compression.
  • Part 3 In this article, Matt Perdeck shows how to enable compression in your development environment, so you can keep track of how large your pages will be as they travel over the Internet to the browser.
  • Part 4 In this article, Matt Perdeck shows how to make your pages more compressible, sets out to settle religeous wars about CPU usage versus savings in page load times, and examines whether compression is the magic bullet.
  • Introduction

    In this final part of the series, we'll tie up some loose ends. We'll see what you can do to make it easier for the server to compress your pages, to further reduce page load times. We'll also look at the trade off between CPU usage and page load time reduction, and a few other compression related topics.

    Improving the compressibility of your pages

    If your server uses compression, then it makes sense to optimize compressibility of your .aspx, JavaScript and CSS files. Compression algorithms like repeating content, which puts a premium on consistency:

    • Always specify HTML attributes in the same order. One way to achieve this is to have all your HTML generated by high-level web controls and custom server controls, instead of low level html server controls. This will slightly increase CPU usage, but will give you assured consistency. For example, write the following:

    Instead of:

    • Likewise, within CSS selectors, write your properties in alphabetical order.
    • Use consistent casing. Use all lowercase for HTML tags and attributes and you'll be XHTML compliant as well.
    • Use consistent quoting: Don't mix "...." and '....'.

    Request and response headers involved in compression

    How does the server know that the browser can accept compressed content? And how does the browser know that the content it received is compressed?

    When a browser that supports compression sends a request to the server, it includes the request header Accept-Encoding telling the server which compression algorithms it supports. For example:

    If the server then uses compression for its response, it includes the response header Content-Encoding in the (uncompressed) file header to say how the file has been compressed, as shown:

    This keeps the browser and server compression-wise in sync. However, it isn't only browsers and servers that send and receive requests and responses, but proxies as well. And proxies can cache responses and serve subsequent requests from their cache. When a proxy caches a compressed file, how do we make sure that the proxy doesn't send that compressed file to a browser that can't process compressed files?

    The solution adopted by IIS 6 and IIS 7 is to tell the proxy that if it receives a request without the Accept-Language request header, it must not serve a file that was sent in response to a request that did have the Accept-Language request header, or vice versa, that is, the Accept-Language request headers must match. IIS 6 and 7 make this happen by sending a Vary header in the response from the server when compression is enabled as shown:

    IIS 6 also lets you override the Cache-Control and Expires headers for compressed files via properties in its metabase. This allows you to suppress proxy caching for compressed files. The IIS 6 metabase was described in part 2, about configuring compression in IIS 6. The metabase properties that override the Cache-Control and Expires headers can be found here.

    Configuring compression in IIS 5

    Based on the fact that IIS 5 is used by only 2.9% of all the websites that use Microsoft-IIS (source), I decided not to include IIS 5 compression in this series.

    However, if you still use IIS 5, you'll find out more about IIS 5 compression here.

    CPU usage versus reduction in page load times

    Whenever IIS compression comes up, some people are worried about the extra load on the server's CPUs, while others focus more on the savings in page load times.

    Although in my personal opinion the extra load on the CPU due to compression is small and the fact that fewer bytes need to be sent down the wire reduces CPU load in itself, the best way to settle this is to measure both the effect of compression on CPU usage and the effect on file sizes, for your specific servers and your specific site.

    In part 3, you already saw how to see the difference in file sizes due to compression with the Web Developer add-on for Firefox and Google Chrome.

    To see the difference in CPU usage, stress test your site with compression switched off and then with compression switched on. Popular stress testing tools include WCAT (free) and the load testing tool included in Visual Studio 2010 Ultimate (expensive). Chapter 14 of my book ASP.NET Site Performance Secrets shows in detail how to use these tools.

    • With compression switched off, start a load generator that puts a heavy load on your test site. This test isn't meant to simulate the real world, so do not use think times. Make sure that the request headers that are sent by the load generator contain Accept-Encoding: gzip,deflate, forcing the web server to provide compressed responses.
    • Run perfmon from the command prompt. Expand the CPU bar. You should find that the IIS Worker Process is the heaviest user of CPU cycles. Write down the Average CPU for that process.

    • Now, do the same with compression switched off.
    • Compare the average CPU usage of both scenarios. Average CPU usage with compression enabled should be higher - unless you use IIS 7 and you cache the compressed versions of dynamic files, in which case you probably see little difference.

    Instead of a stress testing tool, you could also use an online service to generate load against your site. That's much easier and saves you a lot of time, but gives you less flexibility. Some of these services include:

    Is compression the magic bullet?

    With server-based compression dramatically reducing the size of HTML, CSS, and JavaScript files, is there any room for further reduction in file sizes? Yes, there is.

    Introducing AJAX style asynchronous form submission and AJAX style grids and other user interface elements will still make a big difference, even with compression enabled. And if you can do so without too much effort, it is worthwhile to reduce Viewstate, as described in detail in chapter 11 of my book ASP.NET Site Performance Secrets.

    On the other hand, removing repetitive content such as white space will make less sense, because compression algorithms are very good at compressing such content.

    Also, even with compression enabled for dynamic files in your server and most browsers supporting compression, your server will still be sending uncompressed content to some of your visitors:

    • Some anti-virus packages and web proxies strip off or mangle the Accept-Encoding request header going from the browser to the server. That way, the server sends back uncompressed content, which is easier to process for those anti-virus packages and web proxies.
    • In part 1 about configuring compression in IIS 7, you saw that if you cache the compressed versions of dynamic files without using VaryByContentEncoding, a request for uncompressed content will cause the server to send uncompressed content to all clients, until the files expire from cache.
    • You also saw how a spike in CPU load can stop compression until the load drops far enough to re-enable compression.

    To optimize download times when compression has been disabled, you will need to reduce the size of your HTML, for example by reducing ViewState, removing inline JavaScript and reducing white space.

    Find out more

    Here are more online resources about IIS compression:

    Summary

    In this final part, we saw how consistency in the order of html tag attributes and in the use of upper case and lower case can improve page load times by making your pages more compressible. We also saw how you can't always rely on compression.

    I hope you enjoyed this series, and that the knowledge gained here will prove useful to you.

    If you enjoyed this series and want to know the full story on how to improve ASP.NET site performance, from database server to web server to browser, consider my book ASP.NET Site Performance Secrets. Or visit my web site ASP.NET Performance.

    The IIS compression Series

  • Part 1 Starting with this article, I'll show how to get the most out of the compression features built into IIS 7 and IIS 6. This first article focusses specifically on IIS 7.
  • Part 2 In this article, Matt Perdeck shows how to make the most out of IIS 6 compression.
  • Part 3 In this article, Matt Perdeck shows how to enable compression in your development environment, so you can keep track of how large your pages will be as they travel over the Internet to the browser.
  • Part 4 In this article, Matt Perdeck shows how to make your pages more compressible, sets out to settle religeous wars about CPU usage versus savings in page load times, and examines whether compression is the magic bullet.
  • <<  Previous Article Continue reading and see our next or previous articles Next Article >>

    About Matt Perdeck

    Matt has over 6 years .NET and SQL Server development experience. Before getting into .Net, he worked on a number of systems, ranging from the largest ATM network in The Netherlands to embedded software in advanced Wide Area Networks. He has lived and worked in Australia, The Netherlands, Slovakia a...

    This author has published 4 articles on DotNetSlackers. View other articles or the complete profile here.

    Other articles in this category


    IIS FTP User Isolation - Week 46
    This week we walk through the five isolation modes to gain a full understanding of the IIS FTP metho...
    FTP Firewall settings, Active vs. Passive, and FTPS Explicit vs. Implicit Week 47
    Understanding Active and Passive mode for FTP is useful for troubleshooting and ensuring that the fi...
    Q&A. DNS Load Balancing, Google and Geo-location, CDNs-Week 50
    This week answers two Q&A questions from viewers. DNS Load Balancing and then some discussion and a ...
    Q&A. What’s new in IIS8, Perf, Indexing Service–Week 49
    This week I'm taking Q&A from viewers, starting with what's new in IIS8, a question on enable32BitAp...
    IIS FTP Troubleshooting - Week 48
    This lesson covers ways to troubleshoot IIS FTP. When it works, it works well, but if you run into i...
    Top
     
     
     

    Please login to rate or to leave a comment.