We came across this issue lately where performance was degrading gradually and we couldn’t figure out exactly why. What we noticed was that our Page Output Caching that should last 2 hours wasn’t always lasting that long.
The WCM Intranet portal is used by several thousands authenticated (through Active Directory using NTLM) users every day. We have targeted and secured content throughout the site. Page Output Caching is enabled for maximum efficiency (and definitely required for a large audience) along with the other caching mechanisms such as Object Caching (which has been augmented) and application caching.
Unfortunately, in testing environments, we couldn’t originally reproduce the problem as it seemed to be random in production. Also, while we had most of the production content, we hadn’t noticed one critical component : one of the link in the top navigation bar was targeted, as planned, but to multiple audiences instead of a single audience.
Now, this doesn’t seem like a problem, after all, authors are able to do this and we cannot block it. Unfortunately, it seems that as soon as a member of one of those audiences is logging to the site, it will flush all page output caches for that page.
So whenever a page renders a targeted Web Part or a targeted link, if that targeting contains multiple audiences, all caches for that page will be flushed. We are looking at finding a solution with the product and support teams and I will let you know when I have a change of status.
As a workaround, for now, you have to use a single audience to target content. You have 2 choices: compile an audience for that need, or if it’s targeted to multiple active directory groups, create a MOSS group that contains all those AD groups and target the content on the MOSS group.