programmatically control output caching - disable or enable cache according to parameter value

Question

We've got a fairly standard e-commerce scenario with paged lists of products within categories. For better or worse, about 80% of visitors never navigate past the first page, depending on the category there may then be 5-10 more pages of results which are viewed far less often. (Yes we do optimise what appears on the first page and have good search - but that's a different discussion)

We can't cache every single page of results, because we're constrained by memory, but the benefit of caching just the first page of results for each category would be huge.

I know I could do something similar using object caching to store the datasets in question, but is this possible using output caching, perhaps by using the response.Cache object?

Where in the page lifecycle could this be done? Pre-render?

Much simplified, the URL is something like "/ProductList?Category=something&Page=1" And I'd want logic something like (pseudocode):

If paramater "Page" equals 1
   Use output caching: vary by param = "categoryName; page"
else
   Don't use caching at all, just render the page from scratch.

We're using ASP.NET 2.0, on IIS 6/win2003.

Gey

Have a look at the last answer on this post. I hope this helps. – Idiophone

Answer 1

Instead of using the OutputCache directive, you can do the same thing programmatically, as follows:

if (yourArbitraryCondition) {
  OutputCacheParameters outputCacheSettings = new OutputCacheParameters();
  outputCacheSettings.Duration = 60;
  InitOutputCache(outputCacheSettings);
}

Doing this from OnInit should work fine. And obviously, you can tweak the caching behavior by setting the various properties on the OutputCacheParameter, which has all the same knobs as the directive (in fact, that's what we generate when you use the directive).

The key point is that you're only executing this logic conditionally, while the directive makes it unconditional.

UPDATE:

As an alternative, you can use the low level cache API that the code above is built on. e.g.

HttpCachePolicy cache = Response.Cache;
cache.SetCacheability(HttpCacheability.Public);
cache.SetExpires(Context.Timestamp.AddSeconds(60));
cache.VaryByParams["categoryName"] = true;

Basically, it's another way of doing the same thing, without using any API's marked as 'should not be called'. In the end, either way will work, so take your pick.

Gnotobiotics

Works. Any idea why InitOutputCache is EditorBrowsableState.Never and should not be called directly according to msdn.microsoft.com/en-us/library/ms153473.aspx? – Haley

Well, it's mostly due to some lack of forward thinking when we first designed this. There are a number of public/protected APIs on Page that are marked this way. They are all things that get called by generated code as a result of using various syntax, and we figured that the user didn't have any good reasons to call them directly. But the reality is that there is nothing wrong with calling them yourself, and in fact there are times like here where it lets you do things that you couldn't do with the page syntax. I'll file a bug to get those flags removed, though it's way to late for VS2010. – Gnotobiotics

One more thing: you can actually do the same thing by calling the low level cache API directly (and avoid InitOutputCache). It will work the same, but the code will be more complex. Let me know if you want that alternative solution. – Gnotobiotics

Can this work with fragment caching for caching individual controls that are generated dynamically? In other words, what if one dynamic control varies by one parameter, another varies by another parameter? – Sunbonnet

the top code throws and exception if you don't include outputCacheSettings.VaryByParam = "none"; – Gangland

Answer 2

edit: I like David Ebbo's answer a lot better than my own.

---

You could use

<%@ OutputCache Duration="60"  VaryByParam="none" VaryByCustom="pageOne" %>

and implement it in a way that returns a fixed key for the first page and a random key for all other pages. You can (and should) let the scavenging mechanism take care of memory but you can use HttpResponse.RemoveOutputCacheItem to remove cache items if you must.

public override string GetVaryByCustomString(HttpContext ctx, string custom)
{
    if(custom == "pageOne")
    {
        if(ctx.Request["page"] == "1")
        {
            return "1";
        }

        HttpResponse.RemoveOutputCacheItem("/Default.aspx");
        return Guid.NewGuid().ToString();
    }
    return base.GetVaryByCustomString(ctx, custom);
}

Haley

Answer 3

I believe the best way to do this is to use HttpCachePolicy.AddValidationCallback

See http://www.hanselman.com/blog/AdvancedASPNETCachingAndAddValidationCallBack.aspx - There's a full example that answers precisely this question.

Aflcio

Answer 4

You can still use the outputcache directive, and in my opinion, rather than litter your page code with a bunch of caching nuts and bolts, you're better off going with a reusable solution based on handling this in Global.asax the way you normally would any VaryByCustom scenario.

So, for example, if you are using a paging approach with a repeater, you might simply in your search scenario want to exclude any postback on a particular page from the cache. Here is a code example that does just that. The approach merely requires using the HttpContext object to access Response.Cache.SetNoServerCaching(), after trapping whatever criteria for which you wish to avoid caching. I hope this helps.

Mylohyoid

Answer 5

I think you should be able to use the OutputCache directive with the VaryByParam property set to a semi-colon separated list of strings used to vary the output cache.

Unless you were wanting to just cache only when Page == 1?

Tichonn

unfortunately that's exactly what I want (Only when page == 1). If I wanted to cache every page of results that would be easy, using varybyparam as you say. Sorry I don't think I phrased the question very clearly, but what I'm after is only subtely (but significantly) different to the normal scenario everyone is used to. – Gey