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)