IIS7+ - 令人迷惑压缩(Compression)设置

当你在IIS Manage里打开一个网站里的压缩(Compression)功能时，你会发现只有2个选项，分别是启用静态压缩和启用动态压缩。看似设置简单，但IIS_Schema里面对httpCompression的定义内容完完全全出卖了这个“简单”的功能，这是一个只在服务器层能进行配置的节点，而且在UI里只能通过配置编辑器（Configuration Editor）来就行设置，其详细地可设置内容我们可以在下面这个链接中看到：

http://www.iis.net/configreference/system.webserver/httpcompression

 

相信看了以上的可设置信息后我们能意识一些可能导致会一个请求压缩失败的情况，下面总结些本人觉得容易被忽视的：

1. 虽然自带gzip.dll支持gzip和deflate 2种形式的压缩，但默认情况下在模式下只定义了gzip。如果需要进行deflate压缩的，需要手动添加一个deflate模式（同样指向gzip.dll）。

2. 所请求的文件对应的MIME类型没有被添加到静态类型或动态类型中。例如json默认并没有添加到压缩的列表中，需要手动去添加。

3. 静态、动态压缩自动启用和禁用时的 CPU。这个设置意味着只有CPU到达了一定程度压缩才会被启动，而超过了一定CPU时压缩也会被禁用。

4. 可进行压缩的最小文件大小，单位为KB。有时候我们做测试往往会写个很小的文件，小可以，但千万别忽略这个设置。

5. 是否高频率点击的请求。个人认为这个是最坑爹的，因为这个设置并不在httpCompression这个节点下，而是在serverRuntime这个节点下。其判断高频请求的方式是判断一个请求在一定时间内是否发生超过指定的次数，对应的属性是frequentHitThreshold和frequentHitTimePeriod。这2个属性同时也对缓存的设置有效，而在很多文档中都没把这点列为压缩和缓存功能需要注意的事项。

由此可见，和压缩有关的设置其实是非常容易让人迷惑的，如果忽略了其中1，2点，很有可能会对压缩失败百思不得其解。当然还有个比较方便的知道压缩失败的理由是运用失败请求跟踪（Failed Request Tracing，FRT），在FRT日志里面会清楚地写明了压缩失败的原因。最后介绍一篇对压缩的性能进行详细分析的文章：

IIS 7 Compression. Good? Bad? How much?
http://weblogs.asp.net/owscott/archive/2009/02/22/iis-7-compression-good-bad-how-much.aspx

希望这些能够帮助更好的运用IIS压缩的功能。