Alright I've refactored SiteSettings moving the pagecollection and the current page out of its internals so it could be cached.
I've also done a little minor tweaking to the Cache feature that is already built into SiteModule.

I ran a baseline test this morning before making any changes to SiteSettings

Baseline Before Site Settings refactoring




After Refactoring SiteSettings




Then I tried setting a cache time of 360 seconds in the module settings of each module on the test pages.
The next test I ran was actually a little slower so I reviewed the CachedSiteModuleControl.cs and noticed it was using Context.Cache rather than Httpruntime.Cache, wasn't sure if changing that would help but it apparently did. I also made a few other tweaks so that the cache key would be different for users that can edit vs thos that can't and by current culture.

After Applying Tweaked SiteModule cache



Pretty good improvements!

Its going to be challenging to come up with a strategy that really works for the Global.GetVaryByCustomString
The problem is a user may have page edit permission in which case they can edit any module on the page regardless of module specific permission. But a user may also have just edit permission on a module and not all modules on a page so showing the correct edit links for authenticated users could get very complicated.

Still, if its possible to gain 82 requests/sec, that is substantial

Short of that the current caching of siteModule is probably better than caching business objects since it is caching the actual rendered content.

I don't know yet if  ACT can show us the benefit of browser caching. I'll look into it.

Joe

I did some thinking about this last night and it just seemed like it would get too complicated to make sure the right cache copy gets shown to each user without having an explosion of cached copies.
Your suggestions seemed on the right track but thinking through how to implement them my train of thought couldn't quite pull the load ;-). I get the feeling I could spend a lot of time on it and it may not really improve performance as much as the dumb outputcaching does. I think calculating the vary string would not be too bad at the time when the page is being rendered from the db but once its in the cache the logic of having to calculate it correctly based on the user's role cookie, the requested path and all these variables in memory makes my brain hurt.

I think for now I'm going to punt on the page output cache strategy and work on other things, though I'd certainly welcome if anyone else wants to explore implementation of this.

I think the gains we have now are pretty good. I'm going to do some more testing using a remote machine and try to find a few other low hanging fruit performance improvements and then maybe try and ship a minor release before I get back to working on the  SiteOffice features.

It just occurred to me that the way to track the variables needed would be to go the other way from what I just did and add more things to SiteSettings and put it in the cache.

We would need the PageSettings for all the pages within the site (which I just removed ;-)) but in addition to the ModuleCollection for the ActivePage which we had before we would need it for every PageSettings in the collection, this would enable us to do what Bo (kwa) suggested earlier in this thread and just choose the active page from the collection. This would basically be a dictionary of the site pages and modules with roles and with this and the user cookies we would have everything we would need to calculate some kind of string for GetVaryByCustomString()

We could set a timestamp or create a guid string on the SiteSettings object when it is first instantiated and use it as part of the vary string too. This way any dependency that causes the siteSettings cache to be refreshed would start creating a new set of pages.

The formula for the string might be something like
HasPageEditPermission.ToString()
If the user has page edit permision we calculate true for each module in sequence and add it to the string
else we call Module.HasEditPermision in sequence and add that to the string

What do you think Dean? Any flys in the ointment?

Would it be too much to store in memory for very large sites? Other problems? or do you think its worth experimenting with it? Might make initial loads slow when the application starts.