ASP.NET object caching - how much is too much?

Question

Hey guys,

My first time really getting into caching with .NET so wanted to run a couple of scenarios by you.

Question 1: Many expensive objects I've got some small objects (simple int/string properties) which are pretty expensive to instantiate. These are user statistic objects which each user may have 1 - 10 of. Is it good or bad practice to fill up the cache with these fellas?

Question 2: Few cheap regularly used objects Also got a few objects (again small) which are used many times on every page load. Is the cache designed to be accessed so regularly?

Fanks!

stackoverflow: Cracking question suggestion tool btw.

Answer 1

1) I would cache them. You can always set CacheItemPriority.Low if you are worrying about the cache 'filling up'

2) Yes the cache is designed to be accessed regularly. It can lead to huge performance improvements.

Answer 2

The answer to both of your questions is to cache them aggressively if you can.

Objects that are expensive to instantiate yet relatively static (that is unchanging) throughout the application's life ought to be cached. Even relatively inexpensive objects should be cached if you can improve performance by doing so.

You may find yourself running into problems when you need to invalidate the cache when any of these objects become stale or obsolete. Cache invalidation can be a difficult problem especially in a multi-server environment.

Answer 3

I don't think there is any problem with hitting the cache too frequently...

Overall asp.net Caching is fairly intelligent int terms of deciding what to keep and generally managing space. As a rule though I wouldn't depend on the cache to store information, only use it as an alternative to hitting disk or DB. User objects may be better served by session state.

http://aspnet.4guysfromrolla.com/articles/100902-1.aspx is a great article explaining the built in capabilities of .net caching.

Answer 4

Let's address the question in your title - when caching is too much.

It's too much if you are putting so much in the cache that it is pushing other things away. If the web sites on the server in total is using more memory than there is physical memory, they will push each other out into the virtual memory that is stored on disk. That will practically mean that you are caching some of the objects on disk instead of in memory, which is a lot slower.

It's too much if you are putting so many objects in the cache that they push each other out, so that you rarely get to use any of the objects in the cache before they go away.

So, generally you can cache a lot before you reach the limit where there is no point in putting anything more in the cache.

When determine what's most benificial to cache, consider where the bottle necks are. If you for example have a database server with a lot more capacity than the web server, caching the database results doesn't save so much resources. Getting data from the database takes time, but it doesn't use much resources on the web server while waiting for it, so it will not affect the throughput much.