Question

MemoryCache comes with a Default cache by default and additional named caches can be created.

It seems like there might be advantages to isolating the caching of results of different processes in different instances For example, results of queries against an index could be cached in an “IndexQueryResult” cache and result of database queries in a “DatabaseQueryResult” cache. That’s rather contrived but explains the principle.

Does the memory pressure on one cache that results in evictions affect the other caches at all? Are there any differences in the way .Net manages multiple caches compared to how it manages one?

Am I wasting my time considering the idea of multiple caches, or is there real value in doing so?

Answer 1

I can’t speak to the first few questions, and I’m interested to hear answers to those. However, I can say that we’ve been had a good experience so far using multiple caches in our product. Here are the benefits I see:

• Reduced chance of key collision: Rather than coming up with some kind of scheme to ensure that no two separate values end up with the same key, we can simply create a cache that’s specific to a given repository type, and know that as long as that repository class uses keys unique to its objects, we won’t have collisions.
• Better precision with cache eviction: The repository type that “owns” a particular cache instance can subscribe to certain event types on a system-wide event bus, so that it knows when some parts of the cache need to be purged. If we’re lucky, it can determine the keys of the entries to purge purely based on the arguments of the published event. However, this is often not the case, and we must either purge the entire cache or iterate through all the cached values to figure out which ones are affected by the published event. If we were using a single cache instance for all data types in our system, we would end up crawling through a lot of unrelated entries. By using separate caches, we can restrict our search to the values that this particular repository was responsible for populating.

Regarding the second point: we also built a UI to expose all the cache instances in the system, and allow us to purge any of them with the click of a button. This comes in handy when we need to make changes directly to the database, and need the system to pick up those changes without having to restart the server. Again, if we only used a single cache, we couldn’t be nearly as precise: we’d have to purge all the cached values systemwide, instead of just the values associated with the data types that we tinkered with.