Configure dynamic compression in IIS 7.0

In each subsequent version of Internet Information Service (IIS), more options are introduced to control the output cache and compression. For example, when IIS 7.0 is installed for the first time, the compression of static files is enabled by default, and the dynamic File compression function is disabled, especially the. ASP or. ASPX webpage.

Recommended topic: "lecture hall" of IIS service"

Therefore, this function must be manually enabled in IIS 7.0, because the dynamic content may have several problems. Due to some changes in IIS 7.0, static content is now compressed by default, which improves the compression efficiency of the processor.

When dynamic compression is used, one of the options you can set is an ASP. NET application instruction called dynamic compression before caching, which is part of the urlCompression element. Note that you can also use urlCompression to set static and dynamic compression, but most of the time you can only set it through the application's IIS control panel.

So the dynamic compression option before caching or BeforeCache for short) describes how IIS compresses and caches dynamically generated content. When the value of this option is set to TRUE, the content will be generated, compressed, added to a cache, and then output from the cache to the client in sequence. When the value is set to FALSE, the format of the generated content is not compressed. After the request is obtained, the content is compressed again.

Setting BeforeCache to TRUE seems a good idea. If you need to compress many of the same dynamically generated content, it makes sense to compress them once and then use them multiple times. You will save a lot of bandwidth and a lot of CPU cycles. However, in some cases, BeforeCache does not work.

First, according to Microsoft's comment on BeforeCache, "when the output cache response is refreshed, dynamic compression will not be executed until the response enters the output cache ." This means that websites with a dedicated output cache processing method may encounter problems when using BeforeCache, such as providing outdated content or providing custom content to a user.

Another thing to note is: the impact of different types of compression on the cache function. IIS 7.0 supports GNU compression and deflate compression, which are two common types of network client compression. In addition, they are now more reliable, and the compression activity obviously fails in IIS5.0. When a client does not explicitly specify what code it can accept, or when your application cannot process page requests with different codes, the process becomes complicated.

Finally, the webpage is not automatically cached. On the contrary, IIS automatically caches frequently requested content. By default, two or more web pages requested within 10 seconds belong to this type, just as the frequentHitThreshold and frequentHitTimePeriod server parameters are controlled. If a webpage is requested every five minutes, it will not be automatically cached. If people are testing the cache function on a system, but at the beginning they did not generate a suitable load to stimulate the cache.