November Happy Hour will be moved to Thursday December 5th.
AI OnAI Off
November Happy Hour will be moved to Thursday December 5th.
1, Are you sure you're not logged in? Output cache only works for anonymous users and GET requests.
3, If you're doing a lot of (slow) FindPagesWithCriteria, which is not cached, it's good to cache the results, not the actual pages but their PageReferences. GetChildren calls are cached though.
4, It depends of course what kind of objects you store in the cache... the hardest part of caching is to know how and when to invalidate the cache. That's where page dependecies comes in handy. Some objects may be related to a page then it's nice to use that page as a dependency. If you don't know when to invalidate the cache you can at least use the DataFactory Version Key:
public static CacheDependency DataFactoryCacheVersionKeyDependeny()
{
return new CacheDependency(null, new string[] { DataFactoryCache.VersionKey });
}
Hi all,
I'm working on a 6 R2 project at the moment and I have been asked to look into caching the solution as it is expected to experience heavy traffic. We may look at external proxy solutions, but for now we need to explore the options out of the box with EPiServer.
I have a few questions that hopefully this great community can help with.
1) As I understand it from reading http://joelabrahamsson.com/entry/the-episerver-cms-output-cache-explained - it is not necessary to add the outputcache directive at the top of each of the .aspx pages if you have the correct settings on the site node in EPiServer.config AND if your web form inherits from one of the base classes i.e. templatepage. However, I am tracing my application and if I access a page multiple times it is clear there are still plenty of database queries going on. I was under the impression the way outputcache works in .NET is to cache the entire html output and when a request is made for that page, it is served from the output cache, not processed. What would be the best way of diagnosing what's going wrong here, if anything?
Our episerver.config caching config:
httpCacheVaryByCustom="path"
httpCacheVaryByParams="id,epslanguage"
httpCacheExpiration="12:00:00"
httpCacheability="Public"
pageCacheSlidingExpiration="12:00:00"
2) If we decided just to cache the contents of the user controls we would need to add the outputcache directive at the top of each of the .ascx files. I presume for this to work we would also need to disable the caching set in the EPiServer.config file which should be caching the entire page?
3) Another one of Joel's great posts - http://joelabrahamsson.com/entry/how-episerver-cms-caches-pagedata-objects explains how EPiServer caches pagedata objects. What I would like to know is, if EPiServer already caches objects what might a developer want to additionally cache? What are some common objects that you might want to store in EPiserver's cache? Properties are already cached if I understand it correctly, so I'm wondering what types of scenarios/objects arte good candidates for caching?
4) Finally, Ted Gustaf has written a really neat article on caching with page dependencies - http://tedgustaf.com/blog/2010/5/cache-objects-in-episerver-with-page-dependencies/. I understand the implementation, but what I dont quite understand is why you might want to use this approach. For the sake of an example, lets say I want to use a Property from Page B, on Page A. In the code on Page A, I can simply use GetPage to return a PageData object for Page B, which will already be cached, and then grab hold of the property I require. So my question is where might you store objects in the cache that are dependent on another page, which can't already be dealt with by getting access to the cached PageData object?
I'd just like to add that I have only been working with EPiServer for just over a year, so am pretty new to it all, therefore if I have misunderstood, or misinterpreted any of the documentation please accept my apologies!!!
Also, I could have posted these questions on each of the posts that I have referenced, but I thought it was quite a nice collection of articles and examples to pull together in a single thread that may benefit others.
Thanks alot for any input you can provide.
John