I have an application that uses the application cache to store the responses generated but custom HTTP handlers. The same response is always returned to requests for the same URL, and the entire response is inserted whole into the cache.
If an application is caching per-URL, is there any advantage to using the application cache? Or should I just be using the output cache?
Note that because I'm using a custom HTTP handler, all of this is being done in C#, not in page directives.
First I'll state the usual caveat that it depends on the specific case. Factors such as available web server memory, load, page size, data size, etc.
That said, if there are not a huge number of urls and they don't have to be very fresh then the output cache would have the edge I believe. Especially if you are going to do it publicly, that is encourage caching on isp and browser level. Thus saving load on your server and shortening trip for the return user, or user using same isp or proxy.
I would think it would come down to whether or not you need to adjust the settings of the cache programatically at runtime from within your code or not. If you don't then setting the output cache declaratively would be fine.
Assuming you do not use authorization and no dynamic content, the lower level you go the better the results. The lowest level is kernel mode caching. http://learn.iis.net/page.aspx/154/walkthrough-iis-70-output-caching/
Think of it in terms of an office. Technically the request chain is: The boss, a secretary, an answering machine, and the phone line provider.
Imagine an office without a secretary. The boss have to answer every call. This is a scenario without a cache at all.
Application cache is a secretary. It handles the calls so the boss (application) don't have to answer just to tell the same thing over and over. Secretary is someone who sits between the boss and external world. She can handle most simple scenarios. The boss get's bothered when there's no secretary at work (low memory).
But the secretary is a human, so she goes home at some time in the evening (ASPNET application recycles at some time, and application cache get's exposed, so in terms of ASPNET the secretary shares same app donain with the boss).
Here an answering machine comes to play. Not only it can screen a secretary from answering stupid questions over and over again, it screens the boss when no secretary is available. It's just a machine, and the client listens to a nice prerecorded voice or a music (cached item) when neither secretary, no boss can answer them.
IIS caching kernel mode is the answering machine for your asnet "office". An answering machine is much cheaper then a secrtetary. It's just a microcontroller with a tape, it does not even consume coffee, it just plays back a tape or something of that kind.
Well it runs on the same box, but it performs much better, because it just does the simple task of giving out content on maximum speed with it's own low level system resources management.
That said, kernel mode is the perferred way to cache, if you have semi-dynamic content in terms of performance.