IIS 6.0 has a great response caching feature implemented in the kernel-mode http.sys driver. Depending on the app and the load characteristics, it can greatly improve application performance for both static and dynamic pages by caching html responses in kernel mode. The performance improvement comes primarily from eliminating the transitions from kernel to user mode typically needed to service a request.
Response caching works with static files, as well as with dynamic content in ASP and ASP.NET. For ASP.NET, you enable caching through the configuration directive:
But how does http.sys determine whether to cache a page? One way would be to cache each page requested in FIFO order. So once the cache fills up, then the oldest cache entry would be the first to drop off the list. However, it's common for a page to be requested only infrequently, so this would fill the cache unnecessarily.
Instead, pages are cached only if they are requested twice within a configurable activity period, whose default is 10 seconds.
For example, if you have an application that serves stock quotes (this is essentially what http://quotes.nasdaq.com, which runs IIS 6 does) and you're commonly getting requests for quotes for MSFT. Once cached, the response is returned directly from the kernel-mode cache. But what about the price of the stock, which changes? The attribute 'Duration' allows you to indicate how long to cache a response. So if you set Duration=10, you're keeping the response in the cache for 10 seconds.
What happens to kernel mode caching when we use authentication on the web server?
from what I understand any pages that were authenticated can't be included in the kernel mode cache is this true?
You're correct - authenticated pages can't be included in the cache. When you think of requirements for caching authenticated pages, you'd want to ensure that cached pages are sent in a response only to the authenticated user and HTTP.sys can't and shouldn't do such authentication, nor would it be good for it to maintain ACLs, etc. on the cache.
is there any way to "peek" at what's in the http.sys cache (so you can tell if your caching strategy is paying off)?
No, you can't really peek at the http.sys cache (unless you're looking at it in a kernel mode debugger). There's a tradeoff between the amount of things the OS does in kernel mode and performance/stability.
All of these questions plus some discussion I had with <a href="http://blogs.msdn.com/shankun">Shanku</a> prompted some spelunking in the code. Here are the checks done by ASP.NET to determine if a response is cached or not:
Expires header isn't set to "-1"
Has no validation callback
Has no cache item dependencies
Has no cache dependencies
Is not a secure connection
Doesn't require authorization
Has no Substitution blocks (i.e. post-cache substitution)
Has no VaryByParams OR SetValidUntilExpires =true
Has no VaryByCustom
Has no VarybyHeaders
no-store directive not set
What about a page that is a candidate for caching by IIS http.sys and ASP.NET itself. The request comes in, ASP.NET handles it, detects it should cache the output and it does so, then IIS also detects it can cache the output? Would two instances of this same page end up cached (one by IIS and one by ASP.NET)? Or is it ASP.NET somehow detecting that IIS will cache it and avoid caching it itself?