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’ll start by admitting that I’ve never seen the ‘[ACL]#1′ and ‘#1′ instances you mentioned. My understanding is that the difference between the address-only counter set and the address + [ACL] set involves security and whether or not the counter values factor it in. If you have another “set” of counter instances (in your case, the ones including a ‘#1′), perhaps your Web app is extended to additional zones (resulting in additional IIS sites) or makes use of different authentication providers and/or FBA? That question/suggestion is purely extrapolation and guesswork on my part.

When I was doing my earlier troubleshooting work (when the article was written), I know that it was clear to me after some monitoring which set of counters I should be watching. One counter set reflected very little traffic and/or activity, and the other column showed a tremendous amount.

I would guess that where you should look will be a function of how traffic comes into your site collection — or more specifically, through which Web application in your environment the requests are arriving (through one zone? through many zones?) The specific zone you should watch isn’t a question I can answer, but if you see cache compactions anywhere, you should be watching closely. In my experience, cache compactions tend not to occur frequently if they occur at all.

It’s also worth mentioning that things appear to have changed a bit with SharePoint 2010. In my SP2010 farm, each of the Web app-specific counter columns contains no data — just dashes (“—”). All of the publishing counters roll-up under the “_Total” column. Admittedly, my (home) SP2010 environment doesn’t see a lot of traffic. Perhaps my environment is underutilizing some capabilties or isn’t configured optimally, but I hope that what I’m seeing is a sign that it’s easier to read and interpret counter values with SP2010.

It’s not much, but I hope it helps!

- the address itself
- the address itself + ‘[ACL]‘ appended
- the address lower-cased + ‘[ACL]#1′ appended
- the address lower-cased + ‘#1′ appended

All of them are registering slightly different values, which one is the authority?