Pros and Cons of using ASPNET.Core In-Memory Caching instead of Redis? [closed]

Question

Closed. This question is off-topic. It is not currently accepting answers.

---

Want to improve this question? Update the question so it's on-topic for Software Engineering Stack Exchange.

Closed 2 years ago.

Improve this question

I know redis is a very robust caching solution and scales great, but when it comes to simpler non-enterprise websites I feel as if it's a bit too expensive (Azure Standard/C1: $100/m).

I'm considering just creating a simple API that utilizes the Dotnet Core In-Memory Caching.

One benefit of this would be cost, as I could host it in Azure on a Linux app service for less than half the cost of Redis (Azure Linux/Basic/B1: $38.69/m).

With the caching API separate from the main app, it wouldn't wipe the cache for deployments/reboots either.

Would I run into issues with this model? Is there anything with Redis that I might miss? At what point would I strongly need to consider switching to something like Redis?

Answer 1

First, it concerns me that that you use the word "instead". If you want your app to be robust and lightening fast, you should be utilizing both Redis and dotnetcore in memory caching.

Redis will never be as fast (latency-wise) as an in process cache for a compiled application, that's just physics.

Using Redis, may actually well save you money over in process caching once you start needing to scale. If you only utilize inproc, assuming your requests to each server are the same, you will be "wasting" more memory because you have to repeat the cached memory for each server. Using Redis as your primary cache allows you to use a server app server config with lower memory spec which can save you money as you scale.

Dotnetcore caching is also not as easy to code for as you think as it requires you to specify the size of each object. As it fills, if you have not configured things properly, it can cause your application performance and reliability to suffer; for example, you may run out of enough memory to service a request.

Additionally, Redis is not a cache, it's an in memory database, and can provide your application many additional features on top of caching.

The general approach I favor is to keep small, very frequently used, items in the in-process cache, with a short expiry, while caching the larger and less frequently used stuff in Redis for longer periods of time.