views:

5909

answers:

7

I have installed Static and dynamic compression for IIS7, as well as setting the two web.config values at my application ( Virtual Folder ) level. As I understand it, I don't need to enable compression at the server, or site level anymore, and I can manage it on a per folder basis using my web.config file.

I have two settinsg in my .config file that I have set to customize gzip for my app:

<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" />

However, when I run the application, I can clearly see that GZIP is not running, because my page sizes are the same. I am also using YSlow for FireFox, which also confirms that my pages are not being gziped.

What am I missing here? In IIS6 it was a simple matter of specifying the file types, and setting the compression level between 0-10. I don't see the need documented to specify the file types or compression level, since the defaults seem to cover the file types, and I'm not seeing the level anywhere.

+1  A: 

turn on static compression. dynamic compression is for dynamic pages like asp, php, aspx, etc.

Here's a link to the IIS config reference for compression:

Darren Kopp
I don't see where I would need to do that for IIS7. I see it in IIS6, but not 7.
Russ
you can find it in IIS Manager (inetmgr) under the IIS section. open the "Compression" item and check the "Enable static content compression" checkbox.
Darren Kopp
added link to IIS config reference.
Darren Kopp
I see the static compression setting, but I don't really care about that. I want dynamic compression for aspx pages, and no where in the docs can I find where you need to specify the file types.
Russ
must have read your question wrong, apologies. i though you said CSS wasn't geting compressed. i don't know if you can do it in web.config, but i know you can do it in app. do you have the dynamic compression features enabled for IIS?
Darren Kopp
I have it enabled for the web site, but I have tried setting it all the way at the root of IIS as well with no love.
Russ
+8  A: 

There was a thread on forums.iis.net about this during the iis 7 beta. Turned out the guy didn't have the modules installed, but it sounds like you've ruled that out from your opening sentence.

Microsoft' key advice for him was to enable failed request tracing to find out what was going wrong. This is possibly one of the most underappreciated features of IIS7, but certainly one of the most powerful.

Open IIS Manager. Go to your site, and on the actions pane (the very far right), click 'failed request tracing' under the 'configure' section. Click 'enable'. Then, in the features view, click 'failed request tracing rules'. Click add, next, enter 200, next, click finish.

Next, rerun your test. This will generate some log info for us to examine.

Look in c:\inetpub\logs\FailedReqLogFiles\w3svcx. You will see a bunch of files named fr000xx.xml. Open up any one of them in your browser. (By the way, if you copy these files anywhere, make sure freb.xsl is there. Also, don't delete freb.xsl - if you do, just delete the whole directory or copy it from another location, as IIS only creates it once per folder.)

Click the 'request details' tab and select 'complete request trace'. Search the page for 'compress' - you should find it in several areas; once for static content, and once for dynamic content.

If you don't find either of them, IIS isn't configured correctly. If you do find them, you should see them followed by a compression_success and a compression_do. Success is self explanatory; the 'do' indicates what it did - in my case, it showed "OriginalSize 1462784 CompressedSize 179482"

Since yours isn't working, hopefully you will see something different that helps you solve the problem.

Make sure you turn this off when you're done by disabling failed request tracing in the actions pane for your website.

JohnW
this helped! turned out our culprit was dynamicCompressionDisableCpuUsage -- by default, if you hit 90% dynamic compression is disabled and won't be re-enabled until CPU goes back down to dynamicCompressionEnableCpuUsage which defaults to 50% (!!)
Jeff Atwood
+1  A: 

In the system.webServer section of your Web.config file, add the following lines:

<remove fileExtension=".js" />  
<mimeMap fileExtension=".js" mimeType="application/x-javascript" />

The compression scheme in IIS7 is enabled by default, but it maps only a single javascript mime type to be compressed, application/x-javascript. Adding the line above tells IIS to give all your .js files that mime time, which in turn makes the compression work.

jvenema
+3  A: 

We had a similar problem and it turns out that IIS7 does some dynamic CPU based throttling here..

http://www.iis.net/ConfigReference/system.webServer/httpCompression

dynamicCompressionDisableCpuUsage

Optional uint attribute.

Specifies the percentage of CPU utilization at which dynamic compression will be disabled.

Note: This attribute acts as an upper CPU limit at which dynamic compression is turned off. When CPU utilization falls below the value specified in the dynamicCompressionEnableCpuUsage attribute, dynamic compression will be reenabled.

The default value is 90.


dynamicCompressionEnableCpuUsage

Optional uint attribute.

Specifies the percentage of CPU utilization below which dynamic compression will be enabled. The value must be between 0 and 100. Average CPU utilization is calculated every 30 seconds.

Note: This attribute acts as a lower CPU limit below which dynamic compression is turned on. When CPU utilization rises above the value specified in the dynamicCompressionDisableCpuUsage attribute, dynamic compression will be disabled.

The default value is 50.

Note the defaults -- if your IIS7 hits 90% CPU usage, it will disable all dynamic gzipped content until CPU usage dips back below 50%!

Also, some great recommendations and benchmarks here on the real CPU cost of GZIP.

http://weblogs.asp.net/owscott/archive/2009/02/22/iis-7-compression-good-bad-how-much.aspx

Long story short, unless you regularly have dynamic pages well in excess of 200kb, it's a non-issue.

Jeff Atwood
A: 

I solved my problem by installing dynamic compression at Add/Remove programs.

Eduardo
+1  A: 

I have successfully enable GZip on Godday Window Shared Hosting. Refer the web.config configurations needed in this link - http://jeeshenlee.wordpress.com/2010/08/01/how-to-gzip-on-asp-net-and-godaddy/

JeeShen Lee
A: 

Following the excellent advice of JohnW, I too enabled logging to find the culprit, though the reason for the failure turned out to be different:

STATIC_COMPRESSION_NOT_SUCCESS 
Reason 14 
Reason NOT_FREQUENTLY_HIT

That's an obscure one, though luckily I found someone with the same problem, and better yet, the solution.

In short, it appears that if you don't hit the page frequently enough then IIS7 will not deem it worthy of compressing, which seems a little bit odd to me. Nonetheless, makes sense in this case because I was just trying to test it on a local machine.

According to this page, the default appears to be that a page has to be hit 2 times within 10 seconds to be a "frequent hit". If you really want to, you can override the default in applicationHost.config (%systemroot%\Windows\System32\inetsrv\config). At least for me it's a locked attribute, so you won't be able to override it in your own web.config.

<serverRuntime frequentHitThreshold="1" />

Also, I note now that SO already had this answer here: http://stackoverflow.com/questions/2203798/in-iis7-gzipped-files-do-not-stay-that-way.

Gavin Schultz-Ohkubo