IIS 6.0 Compression
They say that you can’t teach “old” dogs new tricks but that certainly is the oldest myth in the business. There are individuals out there that has been breathing IIS inside and out longer than I, but there aren’t many. You can’t deny the simple fact that no one person knows everything —
It is because of this that I sit humbly in a cafe in Tokyo writing the world to say – I learned something new this week. I learn many, many things on a daily basis but often these are around other technologies rather than IIS. The great thing is that I know that every day that I wake there is a possibility that I will learn just a little more than I knew yesterday and hopefully it will be about my favorite web platform — IIS.
To the gist of my post, there is a tricky little part of compression that many individuals out there might not realize. In all my presentations on compression, such as “Using Granular Compression in IIS 6.0” in the IIS Webcast Series I have taught you the following:
- What is static compression?
- What is dynamic compression?
- What extensions are compressed by default for static and dynamic content?
- How do you extend the “strength” level of IIS’s compression attempts?
However, in no presentation or training to date,have I hit or been asked about the metabase property “HcDoOnDemandCompression.” I have certainly hit the metabase property “HcOnDemandCompLevel” but can’t say that for the latter…
This week as I sat in Tokyo training some smart folks about IIS 6.0, a student asked this question and I was stunned. I not only have missed this in all my years but worse off I hadn’t the first clue as to what this property did. I immediately turned sheepish, swallowed my pride, and said “I honestly don’t know what that does.” The ironic thing is that this property can have a detrimental effect on the ability for compression to work hence making it even more ironic that I hadn’t the first clue it existed nor what it did.
Using the help documentation available here – http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/5e346710-94c7-42ff-8377-c029e21af62d.mspx I was able to learn this all-so important fact. In IIS, we give you the ability to control not only what is compressed but more importantly the ability to stop responses to clients from being compressed while still continueing to use compressed data. In a nutshell, if a client requests compression (Accept-Encoding: gzip, deflate\r\n) or a variation of this then IIS will check the IIS Temporary Compression directory (default – %windir%\IIS Temporary Compressed Files) to see if a compressed copy of the file exists. If yes, that compressed response will be sent to the client.
However, if no file currently exists in that directory, IIS will not compress the response after successfully retrieving the files from disk and store it on disk. This behavior is all controlled by this newly discovered property “HcDoOnDemandCompression.” If set to True, IIS will execute on another thread the process of compressing the file but if set to False, we will not.
This was an interesting find and one that had never been sent my direction hence never took the time to read up on it … The moral of the story is if you are using compression in IIS, it is important to make sure that you not only have DoStaticCompression set to True (non-zero) but ensure that you have HcDoOnDemandCompression set to true to make sure “new” files are compressed.
This learning lesson was fun as I had learned something new…I hope this goes the same for you. If you aren’t compressing static content – well, shame on you. You should be even if you are on IIS 5.x where granular compression isn’t available…If your not, then take a hour or so to review the webcast I delivered in the IIS Webcast Series here -
http://www.microsoft.com/windowsserver2003/iis/support/webcasts.mspx#EFAA