Best Solution for Caching

Question

Where is the best place to implement caching in a web based app?

• At the presentation layer (hope not)?
• At the Business Logic Layer?
• At the data layer?

I'm going to use something like memcached or MS Velocity under the hood.

I'm just finding myself writing so much code to update the cache here and there in the business logic layer, so would it be better to create a fabric in between the data access layer at the Database Server to cache data?

I think these complications are down to the fact, most of the data we are caching is user specific and we are duplicating data in the cache. We struggling to find the best solution.

Answer 1

Cache is an important part or a web app, but there is no magical solution that will fit every project. Working on optimisations before your app is working is usually a bad idea. Before asking yourself where you should implement a cache layer, the first step is to be sure that your application works well (even if slowly) without any cache optimisation.

When this first step is achieved, you can start profiling the app, listing the features that seem to be using a lot of resources (may it be CPU, memory, i/o, database access) or taking a lot of time to complete (usually because of the same symptoms).

Once you have a list of features that you think can be optimized with a cache system, there are two questions you need to ask yourself :

• "How can I improve all these features at the same time" (macro focus): An obvious answer to this one is often data-access cache. You usually don't want to send the same query to your database server over and over again if the data you get in return is always the same. So storing this type of data in cache, with a clever lifespan, will always be a good idea.

• "How can I improve each feature" (micro focus): This is tricky, and you need to understand your application very well to figure this one out. Some data can be cached, some shouldn't, some mustn't. A debugger and a profiler are usually great tools for this step, because they help you being sure why a feature is slow, and give you hints about how they should be optimized.

The optimisations you're going to figure out could be related to any layer of your application (presentation, business logic, data), but that doesn't mean you should implement them all. There are several important things you should take into account:

• Does this feature really need to be optimized? (is it a noticeable gain for the customer? For the hardware? For the whole app? For other apps?)
• What performance gain can I achieve? (1%, 200%, ...)
• How much time will it take me to optimize it? (1 hour, 12 days, ...)
• How risky is it to optimize it? (could it break things for the app? For the customer?)

Once you have the answers to these questions, it's time to talk about this with your project manager, with your colleagues, or even with people that don't work on the application with you. Having neutral opinion is good, as well as having non-technical (or less technical) opinions. Talking with these people should help you figure out what should be done and what shouldn't.

At this point you should have a list of optimisations that's pretty clear, that you thought through several times, and you should have no problem coding and testing them.