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"> |
<Provider Name="WWW Server" Guid="{3A2A4E84-4C21-4981-AE10-3FDA0D9B0F83}"/> |
<Keywords>0x40</Keywords> |
<TimeCreated SystemTime="2010-05-13T16:59:08.086Z"/> |
<Correlation ActivityID="{00000000-0000-0000-FD2B-008041000061}"/> |
<Execution ProcessID="10752" ThreadID="14504"/> |
<Data Name="ContextId">{00000000-0000-0000-FD2B-008041000061}</Data> |
<Data Name="Reason">14</Data> |
<RenderingInfo Culture="zh-CN"> |
<Opcode>STATIC_COMPRESSION_NOT_SUCCESS</Opcode> |
<Keyword>Compression</Keyword> |
<freb:Description Data="Reason">NOT_FREQUENTLY_HIT</freb:Description> |
<ExtendedTracingInfo xmlns="http://schemas.microsoft.com/win/2004/08/events/trace"> |
<EventGuid>{E60CEE96-4472-448D-A13C-2170B18220EC}</EventGuid> |
在上面，我们看到了NOT_FREQUENTLY_HIT的字样，看上去响应没有gzip的原因，还是因为没有达到“频繁访问”的要求，即使请求的资源已经被压缩过然后存放在硬盘上了。似乎这个压缩缓存是有一定的时效的，就是过了多长时间就得重新验证一下这个“频繁访问”的逻辑了。
我又进行了大量的测试，发现这个失效时间大约是在5分钟。也就是说，当你频繁访问一个资源，IIS开始对其进行压缩并存放在本地压缩缓存目录之后，大约过5分钟，你再去访问，还是会重新执行“频繁访问”这个验证逻辑。
为了证实我得到的结论，我在推特上向Kanwaljeet Singla（他的推特是@kjsingla）询问了这个问题。出乎我的意料，他很快就回复了我，估计是因为我在做这个测试的时候已经半夜了，他那边刚好是白天的缘故吧。他经过测试，证实“频繁访问”的逻辑检测发生在“响应是否已经压缩”逻辑之前，这确实是IIS7/7.5的一个Bug。
解决办法倒是很简单，只需要将“频繁访问”定义得更宽泛一些即可。例如1分钟内1次访问。
<serverRuntime frequentHitThreshold="1" frequentHitTimePeriod="00:01:00" /> |
(责任编辑：ken)
