IIS Dynamic Compression and new Dynamic Compression features in IIS 10

Dynamic Compression is one of the features that largely goes unnoticed in the everyday work a server does but is one of the unsung heroes of the Internet, saving bandwidth for each packet of data that it compresses. You can find out about how to enable dynamic compression for the IIS web-server by consulting the official documentation which is located here: https://technet.microsoft.com/en-us/library/cc753681(v=ws.10).aspx . You can also read about the benefits of using dynamic compression in this following blog entry: https://weblogs.asp.net/owscott/iis-7-compression-good-bad-how-much .

This article means to discuss the way that dynamic compression can be configured in the IIS web-server, version 7 and above, as well as some new features that have been introduced as of IIS 10 and Windows Server 2016. So let's start with the basics:

IIS Dynamic Compression configuration:

Dynamic compression is a feature that allows the IIS web-server to compress responses coming from such handlers as the ASP.net Managed Handler, ISAPI Extensions or CGI handlers that dynamically generate responses for requests they handle. (For more on handlers and the integrated pipeline, see the video series of IIS Architecture and Components: https://linqto.me/n/IISArchitecture ). Dynamic compression addresses content that is generated dynamically, hence the name, as opposed to static compression, which deals with files that are read from disk and sent across the network to the requesting client (think of PDFs, images, javascript files and CSS files as examples). Contrary to static compression, dynamic compression has to be done on each outgoing response, since there is very little chance that two dynamic responses from a web-application will be the same and the result of the compression of response A will be reused in response B.

By default, the dynamic compression module is not installed on the IIS server if you are just doing a standard install via the Server Manager and choosing to install the web-server role. Hence, and you need to install it by going into the Role Features and checking the 'Dynamic Compression' feature under the Web Server (role) > Web Server (feature) > Performance. The configuration for this feature is done at two distinct levels on the IIS web-server. At the server level we can configure which types of content dynamic compression is enabled for, and what are the cut-off values in terms of CPU consumption for stopping compression from occurring on outgoing responses and resuming it. You can access these settings by clicking on the server name in the left side tree view of the IIS Administration Console, and then selecting the 'Configuration Editor' from the middle pane.

Once inside the configuration editor, you can use the 'Section' drop-down (as shown below) to navigate to the system.webServer/httpCompression configuration section. One very good thing about the Configuration Editor is that it allows you to inspect IIS configuration settings that are available and apply to the location in the tree view (server vs site vs web-application) where you are located. Configuration sections that are not present at the level you have selected cannot be configured at that level, even if you manually try to enter them in a web.config file.

From the listing above, we can see several dynamicCopmpression parameters that are of interest:

dynamicCompressionEnableCPUUsage – this value indicates that underneath this CPU consumption threshold, the IIS server can resume compressing dynamic content. Compression can be a CPU consuming activity, and we want to stop using it if the server's CPU is already quite busy with other computations as to not degrade performance further.

dynamicCompressionDisableCPUUsage –
this is the inverse of the previous value: and indicates at which CPU consumption threshold the server will stop compressing dynamic content so that it does not add any more load to an already overloaded server.

dynamicTypes – this setting is a collection of values, which allows the server administrator to indicate what content types we should be performing dynamic compression on. This is an important change from Windows 2003 and IIS 6, where a server administrator had to list the extensions of all request urls for which the server should be performing static and compression. Starting with IIS 7, we can list content types (MIME types) and can even resort to using wildchar type listings such as text/* - which is actually the first MIME type defined for which the IIS server will attempt to perform dynamic compression for. Note that we can enable or disable compression for each of the listed types as desired. An example of this is the */* MIME type for which dynamic compression is disabled by default.

At the site level
/ web application level / folder level – there are two more settings that control dynamic compression. These two are accessible via the configuration editor when selecting the website / web-application / folder we wish to target from the left-hand side tree view of the IIS Administration Console. The configuration section that contains these settings is the system.webServer/urlCompressionsection. The two configuration values that can be used are:

doDynamicCompression – this setting enables or disables dynamic compression for the website, web-application or folder we are configuring the setting for. It will disable or disable the compression for the MIME types that are listed in the system.webServer/httpCompression section.

doDynamicCompressionBeforeCache – this is an interesting setting whose name might not be self-explanatory. If a dynamic response is determined by IIS to be cachable (will be stored in cache for the next requests), the question becomes: should IIS compress the response before placing it in cache or not? If the doDynamicCompressionBeforeCache is enabled, and the doDynamicCompression is also enabled, and the response is determined to be cachable, the compression will take place before the response is placed in cache. Hence, IIS will store the cached copy of the response. If doDynamicCompression is turned on but doDynamicCompressionBeforeCache is turned off, the response stored in cache will not be compressed. A second request that comes in for the same content on the IIS server will retrieve the content from cache, and the content will have to be recompressed before it is sent to the requesting client. Turning this setting on can greatly contribute to diminishing CPU consumption in some cases.

Determine if dynamic compression is working for your content:

The easiest way to determine if dynamic compression is working for the content that you are serving from your IIS web-server is to use FREB (short for Failed Request Tracing). You can find out more about FREB by looking at thus getting started guide here: /en-us/iis/troubleshoot/using-failed-request-tracing/troubleshooting-failed-requests-using-tracing-in-iis . To determine if dynamic compression is working, consider configuring FREB tracing to trace requests you are interested in: such as request for ASP.net pages (*.aspx) and set the response code to 200 – OK (you can see a lift of all IIS http status codes here: https://linqto.me/IISCodes
) since this is the status code indicating that execution has completed correctly.

Below is an excerpt from the 'Compact View' tab of a FREB trace taken for an ASP.net webpage that shows that the dynamic compression module has activated and compressed the response:

As you can see, the response has been compressed from an initial response size of 4701 bytes down to a response size of 2011 bytes. This is because the response MIME type (text/html) matches the MIME types configured for dynamicCompression (it matches text/*), and that the doDynamicCompression was turned on for the site which served the request for which I had captured the FERB trace for.

New features in Windows 2016 and IIS 10:

In IIS 10 the configuration system of the web-server has been extended to allow the definition of some of the server level configuration sections at the site and web application level as well. We can see this very easily by using the same Configuration Editor to inspect the configuration at site or web-application level. In our case, contrary to Windows 2012 R2 with IIS 8.5 and earlier versions of IIS, the system.webServer/httpCompression section is now also available at the site and web-application level. Note in the screenshot below, the tree view on the left indicates that the website called 'ThrottleTest' is selected, and the Configuration Editor is showing that values of the configuration variables inside the system.WebServer/httpCompression section for this website not for the server level:

You will note that there are six dynamicTypes defined, since I have defined an extra MIME type at the level of my website. This allows a site administrator to define or override the definitions of the dynamic and static compression MIME types that were defined at a server level. This gives a site administrator more flexibility in terms of being able to control the way in which a certain website can deliver dynamic content of a specific type (compressed or uncompressed) while leaving the server's settings unchanged. Hopefully, this will be one more reason for everyone using IIS to consider moving to the version 10 of the web-server.

By Paul Cociuba

Follow what I read: https://linqto.me/about/pcociuba