What are some ways to optimize your use of ASP.NET caching?

Question

I have been doing some reading on this subject, but I'm curious to see what the best ways are to optimize your use of the ASP.NET cache and what some of the tips are in regards to how to determine what should and should not go in the cache. Also, are there any rules of thumb for determining how long something should say in the cache?

Answer 1

The best quote i've heard about performance tuning and caching is that it's an art not a science, sorry can't remember who said it but the point here is that there are so many factors that can have an effect on the performance of your app that you need to evaluate each situation case by case and make considered tweaks to that case until you reach a desired outcome.

I realise i'm not giving any specifics here but I don't really think you can

I will give one previous example though. I worked on an app that made alot of calls to webservices to built up a client profile e.g.

• GET client
• GET client quotes
• GET client quote

Each object returned by the webservice contributed to a higher level object that was then used to build the resulting page. At first we gathered up all the objects into the master object and cached that. However we realised when things were not as quick as we would like that it would make more sense to cache each called object individually, this way it could be re-used on the next page the client sees e.g.

• [Cache] client
• [Cache] client quotes
• [Cache] client quote
• GET client quote upgrades

Answer 2

Unfortunately there is no pre-established rules...but to give you a common sense, I would say that you can easily cache:

• Application Parameters (list of countries, phone codes, etc...)
• Any other application non-volatile data (list of roles even if configurable)
• Business data that is often read and does not change much (or not a big deal if it is not 100% accurate)

What you should not cache:

• Volatile data that change frequently (usually the business data)

As for the cache duration, I tend to use different durations depending on the type of data and its size. Application Parameters can be cached for several hours or even days.

For some business data, you may want to have smaller cache duration (minutes to 1h)

One last thing is always to challenge the amount of data you manipulate. Remember that the end-user won't read thousands of records at the same time.

Hope this will give you some guidance.

Answer 3

It's very hard to generalize this sort of thing. The only hard-and-fast rule to follow is not to waste time optimizing something unless you know it needs to be done. Then the proper course of action is going to be very much dependent on the nitty gritty details of your application.

That said... I'll almost always cache global applications parameters in some easy to use object. This is certainly more of a programming convenience rather than optimization.

The one time I've written specific data caching code was for an app that interfaced with a very slow accounting database, and then it was read-only for data that didn't change very often. All writes went to the DB. With SQL Server, I've never run into a situation where the built-in ASP.NET-to-SQL Server interface was the slow part of the equation.

Answer 4

Some rules of thumb

• Think in terms of cache miss to request ratio each time you contemplate using the cache. If cache requests for the item will miss most of the time then the benefits may not outweigh the cost of maintaining that cache item
• Contemplate the query expense vs cache retrieval expense (e.g. for simple reads, SQL Server is often faster than distributed cache due to serialization costs)

Some tricks

• gzip strings before sticking them in cache. Effectively expands the cache and reduces network traffic in a distributed cache situation
• If you're worried about how long to cache aggregates (e.g. counts) consider having non-expiring (or long-lived) cached aggregates and pro-actively updating those when changing the underlying data. This is a controversial technique and you should really consider your request/invalidation ratio before proceeding but in some cases the benefits can be worth it (e.g. SO rep for each user might be a good candidate depending on implementation details, number of unanswered SO questions would probably be a poor candidate)

Answer 5

Don't implement caching yet.

Put it off until you've exhausted all the Indexing, query tuning, page simplification, and other more pedestrian means of boosting performance. If you flip caching on before it's the last resort, you're going to have a much harder time figuring out where the performance bottlenecks really live.

And, of course, if you have the backend tuned right when you finally do turn on caching, it will work a lot better for a lot longer than it would if you did it today.