I would like to share with you the new way which is possible with SPS2010. All customers are having different business needs in a large Content Deployment scenario and sometimes the default SharePoint design fits exactly but for others not and more manual or scripted “deployment configuration code” is needed.
Here I am talking about configuration settings; using caching or not and why not?
First a picture that tells more than a long dialog:
The right part (Internal) of the picture tells us the default behavior with content publishing.
The left part (Main) is optimized because of business needs with write the content until final published content.
The standard design tells us that any configuration information put into the Content Creation Farm will be also deployed together with all the data to the production. That makes sense for the Internal WebApp but not for the Main one. So what to do now? The solution is to configure the different settings in web.config.
Also a colleague of mine posted already that we have this new functionality http://blogs.msdn.com/b/chunliu/archive/2010/01/08/some-changes-on-caching.aspx
More information you can find in the TechNet article:
Configure cache settings for a Web application (SharePoint Server 2010)
How to configure the example for the left part (Main) above:
There is a line in web.config:
<OutputCacheProfiles useCacheProfileOverrides="false" varyByHeader="" varyByParam="*" varyByCustom="" varyByRights="true" cacheForEditRights="false" />
To enable the cache profile at the Web application level, change the useCacheProfileOverrides attribute, from "false" to "true".
To override the cacheForEditRights attribute, change the cacheForEditRights attribute, from "false" to "true". This will bypass the normal behavior in which people with edit permissions have their pages cached.
In the above Main scenario we recommends the following remediation:
1. On the Content Creation, configure the caches as you would want them to behave on the destination.
2. On the Content Creation, modify OutputCacheProfiles in web.config to useCacheProfileOverrides=”true” and cacheForEditRights=”false”
3. On the Quality Check, modify OutputCacheProfiles in web.config to useCacheProfileOverrides=”true” and cacheForEditRights=”false”
You might find other configuration orders and with the new overwrite feature in web.config you are very flexible now.
The outcome will be:
Your configurations should cause authenticated users on the target to get cached versions of pages; however, authenticated users with edit rights on the Content Creation and Quality Check will not get cached versions.