One of the bigger buzz-word features of IIS 6.0 on Windows Server 2003 is the "HTTP.SYS Kernel Mode Response Cache".
When you do a search against "HTTP.SYS Kernel Response Cache IIS 6", you will inevitably find a large body of literature repeatedly talking about how the kernel mode response cache effectively improves performance and lightens server load by removing the kernel/user mode transitions, improves request/response latency, improves... blah blah blah blah blah... and is the best thing since sliced bread.
Unfortunately, there is not a lot of concentrated, pragmatic information which focuses on the internals of how this cache works so that one can effectively take advantage of this feature. Specially, from within the context of IIS 6.0 and ASP.NET by association since it is an ISAPI Extension DLL.
This lack of consolidated information, along with several newsgroup questions about how the kernel mode response cache works, is what motivated me to write this entry about the background and the raw mechanics of how to leverage this cache from IIS 6.0.
The best way to understand a cache is by understanding how to:
Now, how does this translate to IIS 6.0 using HTTP.SYS?
There are two ways for IIS 6.0 to insert an item into the HTTP.SYS kernel mode response cache:
You must realize that just applying the cache insertion policy does NOT ensure that HTTP.SYS actually caches the response. There are many other variables that affect the cacheability of the response, as documented at this URL.
Of course, there are also limits on what can be placed into the kernel response cache. The most interesting variables from an ISAPI perspective are:
For more info on other registry key tweaks, see:
Personally, I would not tweak with the registry keys unless you know you need to.
The HTTP.SYS kernel response cache, as exposed by IIS, has a very simple cache entry eviction policy - whichever of the following criteria triggers first will flush the associated cache entry(s):
Now, a subtle point with the timing-related eviction policies. HTTP.SYS does NOT immediately evict cache entries when their time is up. Instead, it sweeps through the response cache with a 30 second granularity. What this means is that suppose UriScavengerPeriod is set to 60 seconds. Cache items can between 60 and 89 seconds old, depending on when the cache item was inserted relative to the last periodic sweep.
However, On-Demand invocation is immediate - as soon as you call it, you will get a cache-miss if it used to be a cache-hit.
I hope that my explanation helps clear up the roadmap of how to use this exciting HTTP.SYS feature. If there are any unclear points, feel free to post comments for the benefits of everyone. I will try and follow up with all comments to make this information useful.
Some final observations: