IIS 7.0首次安装时会默认启用压缩静态文件，而禁用动态产生的文件压缩功能的，因此，这个功能必须在IIS 7.0中手动启用，因为压缩动态产生的内容可能会出现几个问题。由于IIS 7.0的某些变化，静态内容现在是默认压缩的，这让处理器的压缩效率更高。

使用动态压缩时，可以设置的选项之一是一个叫做缓存前动态压缩的ASP.NET应用程序指令，它是urlCompression元素的一部分。请注 意，你也可以通过urlCompression来设定静态和动态压缩，但是绝大多数时间你只能通过应用程序的IIS控制面板来设定。

所以缓存前动态压缩选项（或者简称BeforeCache）描述了IIS如何压缩并缓存动态生成内容。当把这个选项的值设成TRUE时，内容会被生 成、压缩、添加到一个缓存，然后按顺序从该缓存输出到客户端。当把值设成FALSE时，生成的内容格式不是压缩的，得到请求之后再重新压缩。

把BeforeCache设成TRUE似乎是一个好主意。如果你需要压缩许多相同的动态生成内容，把它们提前压缩一次然后再多次使用还是有意义的。你会节省大量的带宽以及大量的CPU周期。不过，在有些情况下BeforeCache不会起作用，应该加以说明。

首先，根据微软对BeforeCache的评论，“当输出缓存响应刷新后，在该响应进入输出缓存之前动态压缩不会执行。”这就意味着那些拥有专用输 出缓存处理方式的网站在使用BeforeCache时可能会出现问题，比如说提供过时内容、或者给一个用户提供其他用户的定制内容等。

另一件需要注意的事情是：不同类型的压缩形式对缓存功能会有什么样的影响。IIS 7.0支持GNU压缩和deflate压缩，它们是两种常用的网络客户端压缩类型。此外，他们现在的运行更可靠，在IIS5.0中，压缩活动明显失败。当 一个客户端没有明确指定它可以接受什么代码时，或者当你的应用程序不能处理不同编码的页面请求时，事情会变的很复杂。

最后，网页不会自动缓存。相反，对于那些频繁请求的内容，IIS会进行自动缓存。默认情况下，10秒钟内请求两次或者两次以上的网页都属于这种类 型，就像frequentHitThreshold 和 frequentHitTimePeriod服务器参数控制的那样。如果一个网页每隔五分钟才请求一次，那么它将不会被自动缓存。如果人们正在一个系统上 测试缓存功能，但是开始的时候他们没有生成合适的负载来激发缓存。

注：本站部分信息可能源于互联网分享，如有侵权，请告知，我们将及时删除！