我怎样才能在IIS7工作中获得gzip压缩？
我已经为IIS7安装了静态和dynamic压缩，并在我的应用程序Virtual Folder级别设置了两个web.config值。 据我了解，我不需要在服务器或站点级别启用压缩，我可以使用我的web.config文件在每个文件夹的基础上进行pipe理。
我在我的.config文件中有两个设置，我已经设置为我的应用程序自定义gzip：
<httpCompression dynamicCompressionDisableCpuUsage="90" dynamicCompressionEnableCpuUsage="0"> <scheme name="gzip" dll="%Windir%\system32\inetsrv\gzip.dll" /> <dynamicTypes> <remove mimeType="*/*"/> <add mimeType="*/*" enabled="true" /> </dynamicTypes> </httpCompression> <urlCompression doDynamicCompression="true" dynamicCompressionBeforeCache="true" />
但是，当我运行应用程序时，我可以清楚地看到gzip没有被使用，因为我的页面大小是一样的。 我也使用YSlow的FireFox，这也确认我的网页不被gziped。
我在这里错过了什么？ 在IIS6中，指定文件types是简单的事情，并且在0-10之间设置压缩级别。 我没有看到需要logging指定文件types或压缩级别，因为默认似乎覆盖文件types，我没有看到任何地方的水平。
在iis 7testing版中，forums.iis.net上有一个关于此的线程。 原来这个家伙没有安装模块，但是听起来好像你已经从你的开头语句中裁定出来了。
对他来说，微软的重要build议是启用失败的请求追踪来找出发生了什么问题。 这可能是IIS7中最受关注的function之一，但肯定是最强大的function之一。
- 打开IISpipe理器。
- 转到您的网站，然后在操作窗格（最右边）上单击“configuration”部分下的“失败的请求跟踪…”。
- 点击“启用”。
- 然后，在function视图中，点击“失败的请求追踪规则”。 点击添加，接下来，input200作为状态码，然后点击完成。
如果在操作窗格中看不到“失败的请求追踪”，则需要使用“添加angular色服务”向导（运行状况和诊断\追踪）或通过Web平台安装程序将function添加到服务器（Products \ Server \ IIS：Tracing），然后closures并重新打开IISpipe理器。
接下来，重新运行你的testing。 这会产生一些日志信息供我们检查。
查看c：\ inetpub \ logs \ FailedReqLogFiles \ w3svcx。 您将看到一堆名为fr000xx.xml的文件。 在浏览器中打开它们中的任何一个。 （顺便说一句，如果你把这些文件复制到任何地方，确保freb.xsl在那里。另外，不要删除freb.xsl – 如果你这样做，只要删除整个目录或从另一个位置复制它，就像IIS只创build它每个文件夹一次。）
点击“请求详细信息”标签并select“完成请求跟踪”。 search“压缩”页面 – 你应该在几个地方find它; 一次用于静态内容，一次用于dynamic内容。
如果您没有find它们中的任何一个，则IISconfiguration不正确。 如果你确实find了它们，你应该看到它们后面跟着一个compression_success和一个compression_do。 成功是自我解释的; 'do'表示它做了什么 – 在我的情况下，它显示“OriginalSize 1462784 CompressedSize 179482”
由于你的工作不正常，希望你能看到不同的东西来帮助你解决问题。
确保在完成后closures网站操作窗格中的失败请求跟踪function。
我们有一个类似的问题，事实certificate，IIS7在这里做一些dynamic的基于CPU的节stream。
http://www.iis.net/ConfigReference/system.webServer/httpCompression
dynamicCompressionDisableCpuUsage可选的uint属性。
指定将禁用dynamic压缩的CPU利用率的百分比。
注意：此属性充当dynamic压缩closures的CPU上限。 当CPU利用率低于dynamicCompressionEnableCpuUsage属性中指定的值时，将重新启用dynamic压缩。
默认值是90。
dynamicCompressionEnableCpuUsage
可选的uint属性。
指定启用dynamic压缩的CPU使用率的百分比。 该值必须介于0和100之间。平均CPU利用率每30秒计算一次。
注意：此属性用作较低的CPU限制，低于该限制时，将启用dynamic压缩。 当CPU利用率超过dynamicCompressionDisableCpuUsage属性中指定的值时，将禁用dynamic压缩。
默认值是50。
请注意默认值 – 如果您的IIS7的CPU使用率达到90％，它将禁用所有dynamicgzip内容，直到CPU使用率回落到50％以下！
此外，还有一些关于GZIP的实际CPU成本的重要build议和基准。
http://weblogs.asp.net/owscott/archive/2009/02/22/iis-7-compression-good-bad-how-much.aspx
长话短说，除非你经常有超过200kb的dynamic页面，这是一个没有问题。
根据JohnW的优秀build议，我也使伐木能够find罪魁祸首，虽然失败的原因是不同的：
STATIC_COMPRESSION_NOT_SUCCESS Reason 14 Reason NOT_FREQUENTLY_HIT
简而言之，如果你没有足够频繁地浏览页面，IIS7就不会认为它值得压缩，这对我来说似乎有点奇怪。 尽pipe如此，在这种情况下是有道理的，因为我只是试图在本地机器上testing它。
根据此页面 ，默认情况下，页面必须在10秒内被点击2次才能成为“频繁点击”。 如果你真的想，你可以覆盖applicationHost.config（％systemroot％\ Windows \ System32 \ inetsrv \ config）中的默认值。 至less对我来说这是一个locking属性，所以你不能在自己的web.config中覆盖它。
<serverRuntime frequentHitThreshold="1" />
另外，我现在注意到，这里已经有了这个答案： 在IIS7中，gzip文件不会这样 。
我通过在添加/删除程序中安装dynamic压缩来解决我的问题。
在Web.config文件的system.webServer部分中，添加以下行：
<remove fileExtension=".js" /> <mimeMap fileExtension=".js" mimeType="application/x-javascript" />
IIS7中的压缩scheme默认是启用的，但是它只映射一个javascript MIMEtypes被压缩，application / x-javascript。 添加上面的行告诉IIS给所有你的.js文件MIMEtypes，从而使压缩工作。
打开静态压缩。 dynamic压缩是为像ASP，PHP，ASPX等dynamic页面
这是一个链接到IISconfiguration参考压缩 ：
对我来说，原来是这样的设置
noCompressionForProxies
因为我们在这里是一个代理…把自己从代理和瞧，压缩。
