%@OutputCache vs LoginView

Ian Ryder · May 18th, 2012, 09:52 AM

Hi Imar,

I am hoping you can give me some more advice?

Through your tuition I have introduced Output Caching into my website to speed up loading and I have also added a Login View to my masterpage to show options for an anonymous user vs a logged in user. This is where the conflict of technologies comes into play.

Obviously, I have cached all pages using OutputCache but in so doing I realise that when I have logged into the site the Login View on the pages that I have already visited still show my anonymous user login information since this has been read from the cache and has not been reloaded since the login occurred.

After searching the internet I get the feeling that this is a common problem but I have not come across a solution as yet which is concise and deals with the issue in an efficient manner. I also get the feeling that this could be accomplished by correctly using one of the "VaryBy????" parameters of the OutputCache but I am not sure how to do this as yet?

Can you therefore give me some guidance on the best use of caching technologies when introducing controls such as the Login View control which needs to effectively change the cached page that currently exists.

Kind regards,

Ian Ryder.

Imar · May 19th, 2012, 08:52 AM

Hi Ian,

Here's an article that explains how to cache per user: http://www.zdnetasia.com/how-to-cach...s-39180129.htm

The question is: is that what you really want? The idea of an output cache is that you create a page once and then reuse it many times. If you create unique pages per user, there's a fair chace the cache gets full and pages get ejected without ever being visited again.

I personally wouldn't cache pages that contain user specific information and would focus on standard pages instead. If the data you're displaying is not unique to each user, you could cache that using the data controls or cache API.

Cheers,

Imar

Ian Ryder · May 22nd, 2012, 09:50 AM

Hi Imar,

Sorry for the delay in replying, being trying to get my head round this one?

Based on your comments each and every page of my site is a user specific page since I have placed the Login View control in the masterpage to display whether someone is logged in or not and they then have the ability to logout at anytime. This is what you have demonstrated designing the PlanetWrox site (knowing that you have NOT used outputcache on each page).

What I am struggling to get my head round, is that if you have a Login View in the masterpage then this implies that you CANNOT use the outputcache on any page since this will show incorrect information.

Knowing all that, can you please give me some more guidance on how I could effectively utilise either the cache of the Login View control or the Cache API in the masterpage to achieve what I think you realise is what I am trying to do.

Thanks for any further help you can give on this one Imar.

Cheers,

Ian Ryder.

Imar · May 22nd, 2012, 09:56 AM

Hi Ian,

The idea is to not cache the LoginView. Instead, disable output caching and then cache your data using aching on, for example, the SqlDataSource, or the cache API. This way, the complete page is constructed on each request, but the data that it displays is retrieved from the cache, and thus quick to generate.

You can also use thr Substitution control to do "doughnut caching". However, since it needs to return a string, it's not suitable for complex scenarios such as controls in a LogonView.

Hope this helps,

Imar

Ian Ryder · May 22nd, 2012, 10:42 AM

Hi Imar,

Thanks for that. I have just skim re-read chapter 15 and have seen where you are going with the control caching and API caching. These comments make perfect sense. I had forgotten these points but please forgive me since I am still learning? (I am getting there, honestly!)

That said, your tuition does not quite suit my situation since it is not a data control or a file that I am trying to cache. It is just a plain aspx page with text and pictures and I cannot see any properties that I can set against these controls to implement control caching that would cache the pictures and text in a page and would then leave the masterpage in a dynamic mode.

Am I barking up the wrong tree Imar or is there a way to do this?

Cheers,

Ian Ryder.

Imar · May 24th, 2012, 08:23 AM

If your pages contain mostly static text, there's not much point in caching the entire page as there's not much benefit (processing a plain ASPX page is a relatively quick operation). Output caching is primarily interesing for pages that are viewed often, are not user specific and display data that is relatively hard to get (when it requires database access for example).

Hope this helps,

Imar

Ian Ryder · May 24th, 2012, 09:17 AM

Thanks Imar,

That's interesting and helps a lot when thinking about when to use caching especially when accessing a database.

One thing that I did learn yesterday (browsing the internet) and which does suit my current situation is using partial page caching. That is to say, I design my static information, being pictures and text etc, in a Web User Control which can accept an output cache argument but is then independent of the rest of the page that the control is added to. i.e the MasterPage is not cached and therefore stays dynamic to show my LoginView information correctly.

I have realised that this could be quite a bit of extra work to achieve the desired results but would your experience suggest any reason NOT to use this approach based on your last comments?

Cheers,

Ian.

Imar · May 25th, 2012, 02:36 PM

Hi Ian,

Yes, that makes perfect sense. Should have recommended that as an option earlier....Still, you'll only see real benefits if the content of the UC is hard to create. With static text, I doubt you'll be able to measure the performance increase.

You may want to read the section "When to optimize" and especially the part that says " about 97% of the time: premature optimization is the root of all evil" on this Wiki article: http://en.wikipedia.org/wiki/Program_optimization ;-)

That's not to say that caching isn't necessary, but you should measure first and then determine if you really need it before it affects your design.

Cheers,

Imar