CODEWITHSUNDEEP
asp.netcachingredisdistributed-computingdistributed-caching
LeonCS
LeonCS

Reputation: 33

ASP.NET InProc caching vs distributed cache

I'm looking into Redis and alternatives because we are going to switch to writing our applications distributed. My thought was that we need distributed caching such as Redis to ensure that we have a consistent cache everywhere. My senior colleague does not agree and says that we should just use selective InProc caching, where some data is cached in the machine's memory when it's requested. He also said that Redis will be much slower than caching the data InProc. He agrees that we should store Session state in a distributed cache because that needs to be consistent.

What is the best place to keep a cache? InProc or distributed?

Upvotes: 2

Views: 3568

Answers (2)

user3803723
user3803723

Reputation: 21

InProc and Distributed caching aren't mutually exclusive, or your only options. You can have distributed invalidation solutions as well.

You should also more closely examine what you really need with respect to a "consistent" cache. The only way to guarantee that session state be truly consistent is to lock it. This will serialize simultaneous requests from the same user.

Are you sure you really want/need session state at all? If the things you want to track are security based, are you sure you cannot deal with slightly stale data? If it's user state based, it should likely be rendered into the client page, not independently tracked on the server.

Upvotes: 1

Sameer Shah
Sameer Shah

Reputation: 1083

Using in-proc or out-proc cache is purely application dependent.

Inproc cache stores data in current application’s process memory which makes cached data access very fast however cached data is accessible only to the local application. This works fine if you have only one application server or if every application server is using a different data set. Even so, if the application server goes down, the cached data will be lost.

However if your multiple application server using same set of data, Inproc cache is not the best solution. Since, in that case, every application would be loading the same data set hence limiting the usefulness of using cache. Moreover, for session state caching, it will leave you with the only option of using sticky-sessions which, in turn, would limit load balancing.

On the other hand, distributed caching will add an extra network cost of getting data from another server, but it would give you an advantage of sharing the same data set with all other applications. Not only that but also, the data would remain cached even if the application server goes down.

You can also use a hybrid solution of both Inproc and OutProc caching, like one provided by NCache, where you can have a distributed clustered cache (containing all cached data) and a local inproc cache (containing subset of data, frequently used by that application server). This will give you advantages of both caching techniques.

Since you are re-writing your application, I will recommend you to try NCache. It provides both in-proc and out-proc solutions. You can write your application only once, test it with both solutions and go with the one which suits you best.

Upvotes: 4

Related Questions