On our busy system, it is quite frequent (probably about every ten minutes) that a group is added or deleted somewhere on the system. This causes the core/user_groups_groupings cache to be purged.
I can see why this is done - the intent is to immediately update group information for the user when it changes. core/user_groups_grouping is keyed by user id, and there is no easy way to identify users who have cached data which might be affected by the group being modified, so purging the cache is the easiest solution.
When using memcache(d), purging one cache purges all caches that are stored on the same memcache server, including expensive-to-regenerate caches like course modinfo. Purging the cache frequently is expensive and reduces the benefit from caching. During some operations, we might repeatedly create groups every few seconds, which would be particularly bad - the cache is cleared, the system then struggles to regenerate modinfo for every single course currently being viewed, then it's cleared again, etc.
To avoid this problem (other than upgrading to Redis which I believe can purge individual cache areas), this cache can be configured to store elsewhere, although for users of memcache(d), other caches are likely to be less performant - possibly an issue for this frequently-used cache.
I wonder if there is a way to improve this situation and make the situation clearer to administrators, to avoid hard-to-diagnose performance issues.
One possibility might be to add a cache flag such as USES_PURGE, indicating any cache which is purged during normal operation (rather than specifically when Moodle decides to purge caches when asked by user or during an upgrade), which would display on the cache screen as a warning to users of memcache(d) - or might even prevent the use of memcache for that cache, similar to how you can't choose memcache for caches that require persistency or whatever that other flag is that I forgot.
Does anyone have thoughts? I might be able to implement something like the above.
Note: A similar problem affects the completion caches core/completion and core/coursecompletion, for similar reason (it's cached per-individual). This is triggered whenever anyone deletes any activity anywhere on the system - again, something that would be likely to happen every few minutes during working hours on our system. If a cache flag like the above were implemented then we should add it to those as well.