The ASP.Net platform brought forth many new features and enhancements over the former ASP platform. One of the more significant to be introduced was caching. Previously managed by third-party components, ASP.Net came packed with rich caching options, out of the box. Regardless of whether or not your application is already built and running, it can only benefit from the proper use of caching. This article will explain the various options we have, which will in turn lead to faster applications, and therefore more satisfied users, which can only be a good thing!
How Caching Means More Ca-ching, Part 1 - Output Caching (Page 2 of 4 )
Output caching is probably the least exciting of the three. More or less, we're going to employ this on full pages that wouldn't change more than every few hours. Really though, when we're talking about a dynamic (most often database-driven) application, most of the pages are less pages than they are 'panels', providing little to much functionality, and changing constantly. Perhaps what would qualify more for output caching is something like a Frequently Asked Questions or Help section. This is something that many people will be requesting, but in most cases will not be exceedingly dynamic. This is an area where you could benefit from output caching.
To make use of output caching, we can do it quickly and simply by throwing in the @OutputCache directive at the top of our .aspx page. It might look a little like this:
This will cache the entire page for 10 minutes. That means that everything, including a <%= now() %> block, will remain the same and be served from memory in 10 minute increments. We change this amount of time through the Duration attribute, which takes seconds as its values.
What you're probably wondering about is that goofy looking VaryByParam bit. Don't think that just because it doesn't look like it belongs that you can leave it out. Try it, you'll get a complaint in the form of a runtime error. This is absolutely required. The purpose is to allow a small degree of dynamics to an otherwise static page. We can leave it as the default none, or put it to use caching different versions of the page depending on parameters received either through GET or POST methods.
To explain: suppose we want to cache a different help page for beginner and advanced users. We could set to cache to vary by the parameter of the 'groupID' like this:
and when we request the page -- let's say 'help.aspx' –- like this:
we would get a different cached paged than if we requested the following:
This is pretty cool, as it allows us to be not entirely inflexible. There are two other attributes of the @OutputCache directive, VaryByHeader and VaryByCustom. VaryByHeader is somewhat obvious allowing us to vary the output cache by certain HTTP headers. This would be helpful if we were for instance, caching dynamic output based on languages or user-agents. The third and final attribute, VaryByCustom, can vary the output cache depending on custom settings such as the browser version of the client. This is most likely the least likely to be used. Poor little guy.