Enterprise Server Strategies for the CIOEach successive version of Internet Information Services introduces more options to control caching and compression of output. For instance, when IIS 7.0 is first installed, compression on static files is enabled by default with compression disabled for dynamically-generated files -- typically .ASP or .ASPX pages.
Therefore, this feature has to be
Requires Free Membership to View
enabled
manually in IIS 7.0 for dynamic content since there are some possible issues with compressing
dynamically-generated content. Static content is now compressed by default thanks to some changes
in IIS 7.0 that make compression much more processor-efficient.
One of the options that can be set when using dynamic compression is an ASP.NET application directive called dynamicCompressionBeforeCache -- part of the urlCompression element. Note that static and dynamic compression can also be specified through urlCompression, but most of the time you may just have that set through the application’s IIS control panel.
So dynamicCompressionBeforeCache -- or BeforeCache for short -- describes how IIS handles compression and caching of dynamically-generated content. When this value is set to TRUE, the content is generated, compressed, added to a cache and then queued for output to the client from the cache. When it’s FALSE, the content is generated in an uncompressed form and is recompressed for each request.
Setting BeforeCache to TRUE seems like a good idea. If you have many hits on the same dynamically-generated content, it makes sense to have it pre-compressed once and then served up multiple times. You’ll save that much more bandwidth and that many more CPU cycles. That said, there are some circumstances where BeforeCache doesn’t work as expected, and should be accounted for.
First, according to Microsoft’s comments on BeforeCache (look under the Remarks section), “when the output cache response has been flushed, dynamic compression will not be performed before the response is put into the output cache.” This means sites that their own custom handling of output caching might run into issues using BeforeCache, such as unexpectedly serving stale content or content for one user that’s customized for another.
Another thing to be mindful of is how different varieties of compression can affect caching. Internet Information Services 7.0 supports both GNU zip (gzip) and deflate compression -- the two common types of compression used by Web clients. In addition, they now work a lot more reliably than with, say, IIS 5.0, where the behavior of compression was obviously broken. Things can get complicated when you are dealing with a client that does not explicitly specify which encodings it can accept, or when you have an application that doesn’t deal with how differently-encoded (compressed) pages may be requested.
Finally, pages are not automatically cached. Instead, caching in IIS is triggered automatically for frequently-requested content. By default, this means any page that is requested twice or more in a 10-second period, as controlled by the frequentHitThreshold and frequentHitTimePeriod server parameters. So if a given page is only requested once every five minutes, it’s not going to be cached automatically. This is something that can throw people off if they’re testing caching on a system and not generating an appropriate load to stimulate caching in the first place.
You can follow SearchWindowsServer.com on Twitter @WindowsTT.
ABOUT THE AUTHOR
Serdar Yegulalp has been writing about computers and information technology for more than
15 years for a variety of publications, including InformationWeek and Windows Magazine.
This was first published in April 2011
Join the conversationComment
Share
Comments
Results
Contribute to the conversation