Configuring dynamic compression in IIS 7.0

Each subsequent version of Internet Information Services (IIS) introduces more options to control the caching and compression of output. For example, when IIS 7.0 is first installed, compressed static files are enabled by default, and dynamically generated file compression is disabled, especially .ASP or .ASPX web pages. Therefore, this feature must be manually enabled in IIS 7.0, as there may be several issues with compressing dynamically generated content. Due to some changes in IIS 7.0, static content is now compressed by default, which makes the processor more efficient. One of the options you can set when using dynamic compression is an ASP.NET application directive called pre-cache dynamic compression, which is part of the urlCompression element. Note that you can also set static and dynamic compression via urlCompression, but most of the time you can only set it through the application's IIS control panel. So the pre-cache dynamic compression option (or simply ForeCache) describes how IIS compresses and caches dynamically generated content. When the value of this option is set to TRUE, the content is generated, compressed, added to a cache, and then output from the cache to the client in order. When the value is set to FALSE, the generated content format is not compressed, and is recompressed after the request is received. Setting BeforeCache to TRUE seems like a good idea. If you need to compress many of the same dynamically generated content, it makes sense to compress them one more time and then use them multiple times. You will save a lot of bandwidth and a lot of CPU cycles. However, in some cases BeforeCache will not work and should be explained. First, according to Microsoft's comments on BeforeCache, "When the output cache response is refreshed, dynamic compression will not be performed until the response enters the output cache." & rdquo; This means that sites that have a dedicated output cache processing method may have problems when using BeforeCache, such as providing outdated content, or providing a user with customized content for other users. Another thing to note is how different types of compression affect the caching feature. IIS 7.0 supports GNU compression and deflate compression, which are two common types of network client compression. In addition, they are now running more reliably, and in IIS 5.0 compression activity apparently failed. Things can get complicated when a client doesn't explicitly specify what code it can accept, or when your application can't handle differently encoded page requests. Finally, web pages are not automatically cached. Instead, IIS will automatically cache for frequently requested content. By default, pages that are requested twice or more in 10 seconds are of this type, as controlled by the frequentHitThreshold and frequentHitTimePeriod server parameters. If a web page is requested every five minutes, it will not be automatically cached. If people are testing the caching feature on a system, but at the beginning they did not generate the appropriate load to fire the cache.