“随机”的gzip行为

问题的症状非常简单而又奇怪。有时候连续访问脚本多次，刚开始没有gzip，再次访问又有gzip。等过好一会再去访问，gzip又没有了。有的时候则是无论怎么访问都不给我返回gzip后的响应。

问题的分析

排除了CPU负载过大的因素，因为发现当深夜机器CPU负载正常的时候也一样出现这样的问题。

在系统日志中发现以下Warning条目，引起了我的注意：

Warning    2010/4/13 6:32:41    IIS-W3SVC-WP    2264    None

The directory specified for caching compressed content C:\inetpub\temp\IIS Temporary Compressed Files\XXX is invalid.  Static compression is being disabled.

通过日志筛选，发现从09年7月份就一直出现这样的Warning了，而且出现频率是隔1-3天左右。

这个文件夹是IIS用于存放压缩后的静态内容缓存。按照上面日志的意思，是说这个目录出了问题，导致静态压缩功能被禁用了。但是我明明可以访问这个文件夹，而且里头确实还放着缓存的脚本。

IIS论坛上提这个问题的帖子很多，但最终得到解答的没看到。不过其中一些人的回复倒是给了我不少思路。其中有人说道可能是文件夹权限问题，我看了看那个压缩缓存目录，上面的权限的确是应用程序池的身份，没有问题。使用ProcessMonitor监测了w3wp.exe进程的活动情况，没有看到这个进程在访问文件系统时出现错误。

后来在网上看到了Kanwaljeet Singla（IIS开发团队成员）的一篇文章，介绍IIS7相比IIS6在压缩模块上的改动，文中提到了一点，从IIS7开始，为了降低开销，IIS只对那些频繁访问的静态资源启用压缩。通过IIS7新引入的两个配置选项frequentHitThreshold和frequentHitTimePeriod，我们可以设定，当某个资源在frequentHitTimePeriod时间内被连续访问了frequentHitThreshold次，那么就算是“频繁访问”了。默认的配置是10秒钟内连续对同一Url发起2次请求就算此Url对应的资源属于频繁访问的资源，IIS服务器就会对其进行压缩，然后丢入缓存目录。

这也就解释了为什么有时候第一次请求脚本的时候，服务器没有返回gzip压缩后的内容，而是等你接着下一次访问的时候才会返回gzip响应。

但是按照这篇文章提到的IIS的设计理念，一旦资源被压缩缓存过，那么以后就不会再应用这个“频繁访问”的检测逻辑了，因为毕竟已经没有压缩开销了。而我非常确信这个脚本已经被缓存在服务器硬盘上了，那为什么我过一段时间再去访问的时候还是没有gzip呢？

在IIS7中有一个功能，叫做失败请求跟踪（Failed request tracing），允许技术人员跟踪那些出问题的请求在IIS内部都发生了什么事。为了揭开我的疑问，我对此网站开启了失败请求跟踪。

IIS7的Bug？！

打开IIS7管理器，定位到相应的网站右侧的操作面板，开启“失败请求跟踪”。默认跟踪日志文件是存放在%SystemDrive%\inetpub\logs\FailedReqLogFiles目录中。

然后在功能面板中找到“失败请求跟踪规则”进行配置：

为了防止其他脚本的干扰，在这里我限定了只跟踪测试的脚本

响应状态填写200即可

接下来是选择跟踪提供程序，也就是给你提供跟踪日志源的程序，由于我们的脚本只经过静态文件处理器，因此这里我们只需要选择www server处理程序即可。

然后我们就可以去测试一下访问出问题的脚本了。一旦IIS中途处理遇到些问题，那么就会以xml形式记录下相关的日志。打开FailedReqLogFiles目录，里头会有一些fr000001.xml这样格式的文件，每个文件代表一次失败请求。我们打开这个文件，查找compression关键词，发现了以下内容：

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
 <System>
  <Provider Name="WWW Server" Guid="{3A2A4E84-4C21-4981-AE10-3FDA0D9B0F83}"/>
  <EventID>0</EventID>
  <Version>1</Version>
  <Level>4</Level>
  <Opcode>3</Opcode>
  <Keywords>0x40</Keywords>
  <TimeCreated SystemTime="2010-05-13T16:59:08.086Z"/>
  <Correlation ActivityID="{00000000-0000-0000-FD2B-008041000061}"/>
  <Execution ProcessID="10752" ThreadID="14504"/>
  <Computer>DMZ</Computer>
 </System>
 <EventData>
  <Data Name="ContextId">{00000000-0000-0000-FD2B-008041000061}</Data>
  <Data Name="Reason">14</Data>
 </EventData>
 <RenderingInfo Culture="zh-CN">
  <Opcode>STATIC_COMPRESSION_NOT_SUCCESS</Opcode>
  <Keywords>
   <Keyword>Compression</Keyword>
  </Keywords>
  <freb:Description Data="Reason">NOT_FREQUENTLY_HIT</freb:Description>
 </RenderingInfo>
 <ExtendedTracingInfo xmlns="http://schemas.microsoft.com/win/2004/08/events/trace">
  <EventGuid>{E60CEE96-4472-448D-A13C-2170B18220EC}</EventGuid>
 </ExtendedTracingInfo>
</Event>

在上面，我们看到了NOT_FREQUENTLY_HIT的字样，看上去响应没有gzip的原因，还是因为没有达到“频繁访问”的要求，即使请求的资源已经被压缩过然后存放在硬盘上了。似乎这个压缩缓存是有一定的时效的，就是过了多长时间就得重新验证一下这个“频繁访问”的逻辑了。

我又进行了大量的测试，发现这个失效时间大约是在5分钟。也就是说，当你频繁访问一个资源，IIS开始对其进行压缩并存放在本地压缩缓存目录之后，大约过5分钟，你再去访问，还是会重新执行“频繁访问”这个验证逻辑。

为了证实我得到的结论，我在推特上向Kanwaljeet Singla（他的推特是@kjsingla）询问了这个问题。出乎我的意料，他很快就回复了我，估计是因为我在做这个测试的时候已经半夜了，他那边刚好是白天的缘故吧。他经过测试，证实“频繁访问”的逻辑检测发生在“响应是否已经压缩”逻辑之前，这确实是IIS7/7.5的一个Bug。

解决办法倒是很简单，只需要将“频繁访问”定义得更宽泛一些即可。例如1分钟内1次访问。

<configuration>
    <system.webServer>
        <serverRuntime frequentHitThreshold="1" frequentHitTimePeriod="00:01:00" />
    </system.webServer>
</configuration>

问题真的解决了吗？

当我以为问题圆满解决，满意的睡着之后，第二天测试的时候发现请求脚本又没有gzip了，而且这次是连着访问好几次都没有压缩，这没法用我昨晚得到的结论去解释。让我非常郁闷-_-|||

冷静！

在系统日志中，我又看到了压缩目录无效的警告信息了，但这次，这个压缩目录是真没了。回想起那个时刻做的操作，当时运营的网站抛出未处理的异常，我修改完这个异常就把应用程序池给重启了。难道是说，当网站出现异常的时候，如果强制回收应用程序池的话，会导致静态压缩目录被删除？更奇怪的是，当我再次回收应用程序池，发现这个压缩目录又被重新创建了。

为了验证我的猜想，我又重复了这个过程，让网站抛出异常=>重启应用程序池=>再次请求脚本，问题重现；我又新建了一个一摸一样配置的测试网站，同样的测试流程，却发现压缩目录正常，没有出现上述的症状。

经过细致的对比，我发现运营的网站和我测试的网站环境还是不大一样的。运营的网站时时刻刻都有外部的请求，而且还很频繁。而测试网站不会有任何干扰的流量。

为了模拟真实的情况，我用iMacro写了一个宏，不间断的向测试网站请求该脚本。一开始，可以看到压缩目录确实是存在的，然后我在中途手动回收了应用程序池。发现压缩缓存目录确实被删除了。

经过再细致的测试，我最终得到一个结论：

在IIS7/7.5中，如果为应用程序池配置了administrator的账号权限，那么如果在应用程序池处理静态文件压缩的时候回收应用程序池，会导致压缩缓存目录被删除。直到下次应用程序池健康重启的时候，此压缩缓存目录才会被重新创建。

这个结论我还没有得到IIS团队的证实。但在我几台机器上的IIS7和7.5测试的结果确实都是这样的。联想之前的系统日志中，每隔1-3天就出现这样的问题，刚好是因为IIS7默认的回收间隔是1740分钟，也就是1天5小时。我计算了一下系统日志中的所有关于静态压缩目录警告出现的时间，和这个回收间隔的倍数非常吻合。

解决办法有两个：

• 如果没有必要，则不要给应用程序池配置administrator的账号，使用内置的账号不会出现这样的问题。
• 禁用固定时间间隔回收，改成在一个相对空闲的固定时刻回收，例如半夜4点。

希望我奋战2个晚上得到的结论对你有所帮助~

——Kevin Yang

你可能对下面的文章感兴趣

• 64位系统下IIS7 ISAPI处理器加载失败
• Button标签鼠标点击事件的触发源问题
• IE中使用window.open打开新窗口时无法获取Referrer对象
• IIS7配置Gzip压缩
• Java/Js如何使用正则表达式匹配嵌套Html标签
• Javascript 中的false,零值,null,undefined和空字符串对象
• Javascript中获取出错代码所在文件及行数
• Javascript字符串哈希函数
• Javascript操纵Cookie
• 使用相对Url无缝切换HTTP-HTTPS

本文总结了如何为使用IIS托管的网站启用Gzip压缩, 从而减少网页网络传输大小, 提高用户显示页面的速度.

前言.

本文的知识点是从互联网收集整理, 主要来源于中文wiki.  使用YSlow检测网站启用了哪些优化时, Gzip是十分关键的一项. 启动Gip压缩将立竿见影的减少页面的网络传输大小.

压缩概述

HTTP压缩是在Web服务器和浏览器间传输压缩文本内容的方法。HTTP压缩采用通用的压缩算法如gzip等压缩HTML、JavaScript或CSS文件。压缩的最大好处就是降低了网络传输的数据量，从而提高客户端浏览器的访问速度。当然，同时也会增加一点点服务器的负担。Gzip是比较常见的一种HTTP压缩算法。

HTTP压缩工作原理

Web服务器处理HTTP压缩的工作原理如下：

1.Web服务器接收到浏览器的HTTP请求后，检查浏览器是否支持HTTP压缩；

在用户浏览器发送请求的HTTP头中,  带有"Accept-Encoding: gzip, deflate"参数则表明支持gzip和deflate两种压缩算法.

2.如果浏览器支持HTTP压缩，Web服务器检查请求文件的后缀名；

静态文件和动态文件后缀启动要所都需要在MetaBase.xml中设置.

静态文件需要设置: HcFileExtensions Metabase Property (单击跳转到MSDN说明)

动态文件需要设置: HcScriptFileExtensions Metabase Property (单击跳转到MSDN说明)

3.如果请求文件是HTML、CSS等静态文件并且文件后缀启用了压缩，则Web服务器到压缩缓冲目录中检查是否已经存在请求文件的最新压缩文件；

4.如果请求文件的压缩文件不存在，Web服务器向浏览器返回未压缩的请求文件，并在压缩缓冲目录中存放请求文件的压缩文件；

5.如果请求文件的最新压缩文件已经存在，则直接返回请求文件的压缩文件；

6.如果请求文件是ASPX等动态文件并且文件后缀启用了压缩，Web服务器动态压缩内容并返回浏览器，压缩内容不存放到压缩缓存目录中。

在IIS6中启用HTTP压缩

IIS默认并不支持HTTP压缩，需要进行简单的配置

1.打开Internet信息服务(IIS)管理器，右击"网站"->"属性"，选择"服务"。在"HTTP压缩"框中选中"压缩应用程序文件"和"压缩静态文件"，按需要设置"临时目录"和"临时目录的最大限制"；

2.提醒: 经试验此步骤在本人机器上没有作用, 可以忽略.

在Internet信息服务(IIS)管理器，右击"Web服务扩展"->"增加一个新的Web服务扩展..."，在"新建Web服务扩展"框中输入扩展名"HTTP Compression"，添加"要求的文件"为C:\WINDOWS\system32\inetsrv\gzip.dll，其中Windows系统目录根据您的安装可能有所不同，选中"设置扩展状态为允许"；

3.使用文本编辑器打开C:\Windows\System32\inetsrv\MetaBase.xml(建议先备份),

找到Location ="/LM/W3SVC/Filters/Compression/gzip用于设置gzip压缩，

找到Location ="/LM/W3SVC/Filters/Compression/deflate"用于设置deflate压缩.

上面两个节点紧挨着.并且设置的属性相同.

如果需要压缩动态文件，则将HcDoDynamicCompression设置为"TRUE"，并在HcScriptFileExtensions中增加您要压缩的动态文件后缀名，如aspx；如果需要压缩静态文件，则将HcDoStaticCompression和HcDoOnDemandCompression设置为"TRUE"，并在HcFileExtensions中增加您需要压缩的静态文件后缀名，如xml、css等；HcDynamicCompressionLevel和HcOnDemandCompLevel表示需要的压缩率，数值在0-10, 默认为0.

HcDynamicCompressionLevel属性说明:HcDynamicCompressionLevel Metabase Property

HcOnDemandCompLevel 属性说明:HcOnDemandCompLevel Metabase Property

说明: 这两个属性值一般推荐设置为9, 具有最佳性价比.但是在我的window server 2003上, 压缩率无论如何设置, jQuery和jQuery UI两个文件(58k/188k)压缩后的大小一直相同.(20k/45k). 

下面是我的实例:

<IIsCompressionScheme Location ="/LM/W3SVC/Filters/Compression/deflate" HcCompressionDll="%windir%\system32\inetsrv\gzip.dll" HcCreateFlags="0" HcDoDynamicCompression="TRUE" HcDoOnDemandCompression="TRUE" HcDoStaticCompression="true" HcDynamicCompressionLevel="9" HcFileExtensions="htm html txt js css swf xml" HcOnDemandCompLevel="9" HcPriority="1" HcScriptFileExtensions="asp

aspx dll exe" > </IIsCompressionScheme> <IIsCompressionScheme Location ="/LM/W3SVC/Filters/Compression/gzip" HcCompressionDll="%windir%\system32\inetsrv\gzip.dll" HcCreateFlags="1" HcDoDynamicCompression="TRUE" HcDoOnDemandCompression="TRUE" HcDoStaticCompression="true" HcDynamicCompressionLevel="9" HcFileExtensions="htm html txt js css swf xml" HcOnDemandCompLevel="9" HcPriority="1" HcScriptFileExtensions="asp

aspx dll exe" > </IIsCompressionScheme>

4.编辑完毕后保存MetaBase.xml文件；如果文件无法保存，则可能IIS正在使用该文件。打开"开始"->"管理工具"->"服务"，停止"IIS Admin Service"后，即可保存；

5.最后，重新启动IIS。可以到HTTP压缩测试网站验证结果.以jQuery为例, 核心类库和UI类库原始大小分别是57k和188k,压缩后分别是20k和45k:

我们通过Http头中的: Content-Encoding:gzip 属性判断返回后的数据已经启用了gzip压缩:

使用YSlow检测, 当只启动静态文件压缩时, Gzip压缩评级为B:

当同时启动了动态文件压缩时, Gzip压缩评级为A:

要点总结

1. 在修改MetaBase.xml文件时, 要停止"IIS Admin Service"服务. 否则无法保存.

2.静态压缩和动态压缩率最好设置为9. 

3.上文的步骤2, 即使不添加Web服务扩展效果也是相同的.

4.压缩率设置对js文件不起作用, 压缩后大小总是相同的.

5.图片文件即使启用了gzip压缩大小也没有变化.

你可能对下面的文章感兴趣

• 64位系统下IIS7 ISAPI处理器加载失败
• IIS中使用子目录文件作为默认文档（Default Document）替代重定向
• Silverlight启用Assembly Caching之后铁通用户无法访问
• 【推荐】两款HTTP流量分析工具的比较
• 为什么IIS7/7.5的Gzip不起作用
• 使用相对Url无缝切换HTTP-HTTPS
• 当Google Analytics、Firefox和IIS走到了一起…