Home > IIS Stories > Enabling HTTP Compression to save network cost in IIS (#3/3)

Enabling HTTP Compression to save network cost in IIS (#3/3)


In previous posts, we could review ‘How to enable HTTP compression’ in IIS6, & IIS7 servers. It’s time to review ‘Why’ from now on. The reasons can be saving available network bandwidth by minimizing sizes of responses from IIS servers. But, as you can see ‘compression on-the-fly’ settings in IIS7, there can be concerns & overhead of CPU utilization in IIS server.

In IIS7, using HTTP Compression for static contents is enabled by default, and it makes sense because that can be a good idea for static contents for many sites. Once IIS compress a static file, the file is being cached, and reused. In terms of compression for dynamic contents, it’s required to review gains of available network bandwidth, with CPU overhead, caused by enabling compression.

However, in a real world, things are not simple.



HTTP Compression – Pros & Cons

Generally, we think IE(Internet Explorer) sends a request, and IIS replies with ‘Responses’. If you review network captures between IE & IIS, they’re composed of a single, you can find there’s a single(or a few) network packets for Requests from IE, and more than a few(or many) packets for Response from IIS. Number of network frames(or packets) depends on MTU(Maximum Transmission Unit), which is 1500 bytes by default for most network environments. This means any packets greater than 1.5k, should be split. let’s say IIS server has 6k to be sent, the number of packets is about 6k/1.5k( = 4 packets).

So, this means that HTTP compression can help IIS server to reduce number of packets. In this case, it can save CPU utilization too, because managing & sending packets to the network interface, are CPU operations should be done in time. If a compressed output became 1.4k, and its original size was 14k, number of packets to be sent, can be reduced by 10% – then, CPU is happy too.

. Compression’s Reducing number of packets can save both network & CPU cost.

. HTTP Compression enables you to deploy more services by reducing front-end network traffics.

If you have used PC more than a few months, you already know that a compressed file size can’t be expected before compressing it. It does depend. This is for IIS too. For some contents, it doesn’t reduce its size, or number of packets enough. This means HTTP compression doesn’t help.

. HTTP compression may causes just CPU overhead with less gains of network bandwidth.

It’s not so difficult to find that there’s no benefit to use HTTP compression for some contents.

For dynamic contents, responses from IIS, are mostly text data, which has a good compression ratio. So, it’s required to check saved network bandwidth & CPU overhead by compression. Dynamic compression is not enabled by default, and requires your test to be applied for your system. Anyway, testing is a burden, it spends hours, or days, and needs to keep updated. This is quite challengeable for those who don’t have any organized testing process & tools for large web sites.

. Testing web sites to measure benefits of HTTP Compression can be challengeable for IT staff.

In summary, in an ideal & hopeful situation to use ‘HTTP Compression’ feature, can be as follows,



. %CPU time increased temporarily, to compress static contents for first requests

. %CPU time was being decreased after having enough cached contents

. %CPU time became lesser & stabilized, when IIS hits high utilization of cache, managing smaller size of contents & packets.

. Size of responses have been minimized quickly, and increased available bandwidth.

(The above is ideal situation, can be expected theoretically.)


How to measure the performance gains

Someone may want to use Fiddler to check bytes-received from IIS, as long as there’re not many requests to review. Fiddler is a useful tool to review individual round-trips between IE & IIS. It’s also useful to check if HTTP Compression is enabled or not by checking response headers. But, using Fiddler is not practical for testing whole web sites, or server farm that has large scale of contents. We need a better way.

When we want to check performance gains from HTTP Compression, it’s about size of data from IIS to IE. Then, we have IIS log files, which includes SC-BYTES field that means ‘number of bytes sent, server to client’. Once IIS compressed a content, it’ll be sent to the browser, and record its size to the IIS log.

A default log path in IIS7 – ‘C:\inetpub\logs\LogFiles\W3SVC1’

A default log path in IIS6 – ‘C:\Windows\system32\LogFiles\W3SVC1’

(W3SVC1 is only for a default web site after IIS installation).

A logging field – sc-bytes, is not enabled by default, so you need to use IIS manager to enabled this,


Open logging feature, check ‘Bytes Sent’, and click ‘Apply’.


In IIS6, you can complete this in IIS manager, open a ‘Properties’ window at a web site, and change logging options to select ‘sc-bytes’ field. You don’t need to run IISRESET’ to apply this change.

Once you have ‘sc-bytes’ filed in IIS log files, you can count them by reading IIS log, or you can use ‘Log Parser’ tool to sum bytes sent.


I think you don’t want to read log files to check a lot of records.


How to use ‘Log Parser’ tool to count sc-bytes

. At http://download.microsoft.com , use a keyword ‘Log Parser’ to search and download it.

  (It’s Log Parser 2.2 at the moment)

. Install the downloaded package, and copy logparser.exe to a system path(such as c:\windows\system32), or copy it to the same folder with IIS log files.

. Run the below query in a command prompt,

logparser “select sum(sc-bytes),avg(sc-bytes) from your_logfile_name.log to output_filename.csv” –o:CSV

. For example,


Open output.txt,


The queries in a log parser command, can be customized for your own need. It supports a standard SQL to used with logparser command, and it also support various output formats. Refer the help of logparser tool for details.

Although you have many thousands of records in IIS logs, it doesn’t matter to check IIS logs if you use the log parser tool. You just need to enable all the required logging fields in IIS manager, and prepare your own useful query to run. It’s also a good idea to build a batch script that includes logparser commands. In general, you need to use where conditions carefully in your queries to specify duration, or contents to check.

For example,

logparser “select count(*), sum(sc-bytes), avg(sc-bytes) from ex*.log to chk.txt where time>’07:10:00’ and cs-uri-stem like ‘%.aspx’ ORDER BY count(*) DESC” –o:CSV

By using Log Parser tool, you can check performance gains for bytes-sent per given duration, such as ‘per minute’, or ‘per hour’ during your test.

For your information, there’re performance counters to measure bytes sent by IIS. You can try to use performance monitor to collect historical values of bytes(Web Service\Bytes Sent/sec), ‘%Processor Time’ and so forth. I didn’t tested & checked the counters for HTTP compression whether performance counters can be reliable or not.

To measure %CPU Time, it’s good idea to use ‘Performance Monitor’, rather than a task manager, that shows current values only.

To open performance monitor, click [Start] – [Run], and type perfmon to run.


You need to add ‘Processor\%Processor Time’ to check average, or current value of %CPU.


If the testing duration is long(more than a few minutes), then you need to create a performance counter log to monitor counters under ‘Processor’ object, instead of using an chart as shown above.

For Windows 2003, http://support.microsoft.com/kb/248345/en-us

For Windows 2008, http://technet.microsoft.com/en-us/library/cc753012

You can measure performance gains in your production system, by using IIS log files, & Performance Monitor, but you may need constant loads(number of requests, and requested contents) for a test purpose. In this case, you need a stress tool, with a prepared script to simulate user loads. This article is not going to handle those topics, because this’s already long article enough. Winking smile

Instead, I’d like to recommend an interesting test & result to review,

IIS 7 Compression. Good? Bad? How much?



Many references are recommending you to utilize HTTP Compression feature, and there’re also many questions those are saying ‘it doesn’t make differences’.
I’d like to mention that your web sites are special, and not ordinary. I can’t guess anything about your web sites, so you need to test & verify it.

Categories: IIS Stories
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: