问题真的解决了吗？

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

冷静！

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

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

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

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

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

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

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

解决办法有两个：

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

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