issue with output caching in episerver

Shamrez Iqbal

Vote:

We've stumbled upon a problem which community fellow Vladimir Vedeneev has blogged about here: http://world.episerver.com/Blogs/Vladimir-Vedeneev/Dates/2011/3/Cache-and-GoogleBot/ The issue is basically that asp.net has caches things diffrently depending on the client browser accessing the site.

Anyways, in this blog post one of the proposed solutions are to add httpcachevarybycustom=browser in additon to the path setting but Vladimir writes,

"There are several side-effects. First of all, a page will be cached separately for each browser and its major version combination, which will dramatically increase memory used by server output cache. Another thing is that EPiServer may believe in “path” setting here to vary cache by Url.Path."

Could somebody enlighten me a little bit on what he means by the last (highlighted) issue?

#54364

Oct 12, 2011 8:47

Håkan Lindqvist

Vote:

I just now posted a comment on this to the blog post referenced, I'll quote myself here:

Regarding the default value of httpCacheVaryByCustom being "path", the reason for that, as I understand it, is that in some scenarios the same page may exist in different paths (eg http://www.example.com/ and http://www.example.com/en/) and if there are relative paths in the output, one of the pages would have broken paths if they would share output caches.

Which means that depending on how the site is set up and coded you may need "path". In that case it would be possible to create your own custom VaryByCustom handling that combines the browser and the path behavior.

Sticking something along these lines in global.asax.cs (inheriting from EPiServer.Global) + changing the config accordingly ought to work in that scenario (not tested):

public override string GetVaryByCustomString(HttpContext context, string arg)
{
	if (arg == "browserandpath")
	{
		return base.GetVaryByCustomString(context, "browser") +"|"+ base.GetVaryByCustomString(context, "path");
	}
	return base.GetVaryByCustomString(context, arg);
}

See http://msdn.microsoft.com/en-us/library/5ecf4420.aspx for details.

#54370

Oct 12, 2011 11:35

Shamrez Iqbal

Vote:

Hi Håkan, thanks for the reply,

what I'm wondering is that since VaryByCustom is supposed to be a comma-delimited list of strings, shouldn't it be sufficient to have the setting set to varybycustom="browser,path" so that it respects both variables since browser is already a recognized string by asp.net ?

At least the official msdn documentation claims that the value is a comma-seperated list but i haven't found anything using reflector which would indicate that it actually splits the value..

#54390

Edited, Oct 13, 2011 8:13

Håkan Lindqvist

Vote:

MSDN seems to have some conflicting information on this but my impression is that VaryByCustom, as opposed to the other VaryBy* options, does not actually have any built in support for multiple values. (It appears to just call GetVaryByCustomString in the current System.Web.HttpApplication with the specified string as the argument.)

If that is a misunderstanding on my part and it's actually supported somehow, then definitely go with just specifying a comma-separated list.

#54405

Oct 13, 2011 10:22

Try our conversational search powered by Generative AI!

issue with output caching in episerver