1

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?

closed as off-topic by amon, gnat, Greg Burghardt, BobDalgleish, Bart van Ingen Schenau Feb 19 at 11:16

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions asking us to find or recommend tools, libraries, programming languages, resources (including books, blogs, tutorials, and examples), or projects to undertake are off-topic here as they attract opinionated answers that won't have lasting value to others. You may be able to get help in The Whiteboard, our chat room." – amon, gnat, Greg Burghardt, BobDalgleish, Bart van Ingen Schenau
If this question can be reworded to fit the rules in the help center, please edit the question.

0

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.