Thanks for the feedback; I’m glad that you found the article useful!

You asked about the object cache getting flushed if list data changed. The answer to that question depends on your selection for the “Cross List Query Cache Changes” option on the Object cache settings page (from within Site Settings for the site collection). You have two options available to you: “Check the server for changes every time a cross list query runs” and “Use the cached result of a cross list query for this many seconds.”

If the former option is selected, then a change check is made each time a query is run to determine if data is stale; if it is, then the cache is flushed and refilled. If no changes have been made, then cached data is used and better performance is obtained.

If the latter option is selected, cached data is used regardless of whether or not list item data changes have taken place. This results in the best overall performance, but it does come at the cost of some potentially stale data.

Since the data that the object cache holds in memory isn’t supposed to change that often (certain web properties like Title, navigational data if you’re using something like the PortalSiteMapProvider, cross-list/cross-site query information), caching without change checks is usually deemed acceptable. The performance improvements gained outweigh the potential negatives of stale data and having to check for changes on every request. Microsoft drew this conclusion in the move from SharePoint 2007 to SharePoint 2010, as well; in 2007, the server was checked for changes every time a cross-list query was run by default. In 2010, the default is to cache cross-list results for a fixed period of time without change checks.

To your final point: yes, cache flush and fill is an expensive process. If you have absolutely no tolerance for stale data, then you really don’t have any option and need to check the server for changes with each query. In the majority of the environments I’ve seen, though, data turns over frequently but can survive some small amount of “staleness.” A cache duration of 60 seconds isn’t that much to tolerate from an end-user perspective, but that amount of time can save a tremendous amount of back-end processing in environments where large numbers of queries are being run (e.g., a site with many Content Query Web Parts that are rolling up data) to display data.

Remember: even if a user goes to edit data, they’ll be going directly to the lists and libraries housing it — and that data will be up-to-date regardless of the state of the object cache.

I hope that helps!

I also looked at the Blob cache technique. Blob cache and object looks to be a solution to over come the problem of dead slow applications here. A couple of questions below….

But i would like to know if there are any contraints or points to be noted( which might drive me back home) if both Blob cache and object cache are implemented.

Object cache refers to the queries (most of the times). So what if the list data is changed. Does the Cache get flushed and filled( irrespective of the Cache expiry time).

A point noted from the above article.. Cache flush, fill and serve is a costly operation. So if the list which gets frequently updated is cache enabled – sounds like an adverse effect. Can you throw some light on this.

Thanks

I haven’t played with setting the headers directly (I’ve relied on BLOB caching for that), but the ones you specified should generate similar results to those produced by the BLOB cache’s max-age attribute setting. The technique in the article describes doing them on a page-by-page basis, and I imagine that would get tedious pretty quickly … but it would be a good way to prove-out whether or not the technique will work for you. If it does, I recommend incorporating the header additions into an HttpModule for broader (and easier) use.

If you’re going to set the cache control headers for specific pages rather than normally static assets like images, javascript, etc, be careful. Some pages in SharePoint are truly static, but just as many aren’t and require some rendering change (or consideration for user, query string parameter, etc.) in a postback scenario. If you’re going to start caching entire pages (as is typically accomplished through page output caching in MOSS or SharePoint Server 2010), you’re going to need to test, test, and then test some more to make sure that you aren’t inadvertently caching a page with content that is dynamic and should be re-rendered/changed on a postback.

- Sean

Thanks for your speedy and very informative reply!
I’ll start with JS optimizations as you suggested. And the HttpModule option makes sense as well.

What do you think of using the HTML tags META HTTP-EQUIV=”EXPIRE” and “CACHE-CONTROL” ?
I see it mentionned here http://msdn.microsoft.com/en-us/library/bb727371(v=office.12).aspx#MOSS2007OptPerfWCM_PagePayloadSmallisGood but I’m not sure if it’s applicable to Foundation 2010.

Thanks for your help!
Guillaume

Max-age headers are tied to BLOB caching, and BLOB caching is controlled through SharePoint Server’s PublishingHttpModule (which I described in more detail here: http://sharepointinterface.com/2009/06/18/we-drift-deeper-into-the-sound-as-the-flush-comes/). The PublishingHttpModule only comes with SharePoint Server, so obviously SharePoint Foundation isn’t going to give you any help. You’d be reinventing the wheel a bit, but there’s nothing stopping you from writing an HttpModule yourself that evaluates incoming requests and applies the appropriate HTTP cache control headers to carry out client-side caching of specific assets. In terms of actual coding effort, it wouldn’t be at all prohibitive.

Besides cache control headers, you might see a more consistent across-the-board improvement by simply controlling how much javascript goes to the client browsers (I’m assuming they’re anonymous). Core.js, for example, is hundreds of kilobytes of scripting that really doesn’t need to go to client browsers in anonymous usage scenarios. Chris O’Brien over in the U.K. wrote a nice post (with code sample) on trimming down javascript requests, such as core.js, with some in-line code: http://www.sharepointnutsandbolts.com/2011/01/eliminating-large-js-files-to-optimize.html

I hope that helps!

Thanks
Guillaume

Actually, I was thinking about the UPS, if it is the main causing of the issue? because TIMER Service is crashing for each time when the synchronize job is started!!
But after I read your post and follow the steps,the issue resolved :)

Thanks again for the good troubleshooting and explaining,