I am a Full stack .NET Developer, I like to work with C#, Asp.Net Core, SQL, Mongo DB, Azure, JavaScript...
Always eager to learn new technologies. I am here to share, ask & eventually learn.
😄, Nice, But why you want to store cache in-memory ?, I think in-memory cache is not good for high traffic websites. If we store cache in same computer where application is hosted i think the application will not scale for large traffic. So Isn't it good to Make cache distributed in another computer using Redis ?
An in memory cache hit is much faster than a redis hit. My boss' previous job used messaging (like MSMQ/RabbitMQ) to do the propagation, it got sub 10ms response times on full hot cache hits from what I recall.
Distributed in process in memory caching is a strategy to push high traffic web app response times beyond what a distributed out of process caching system like redis or couchbaae can give you.
It's basically applying the caching mechanisms of DNS and globally distributed CDNs in a web app.
I am a Full stack .NET Developer, I like to work with C#, Asp.Net Core, SQL, Mongo DB, Azure, JavaScript...
Always eager to learn new technologies. I am here to share, ask & eventually learn.
In-memory caching is great and is super fast but remember, this is about a multilayer cache where we can play to the strengths of multiple different types of cache. Redis is fast but in-memory in the same process will always be faster.
Distributed caches like Redis have two major benefits - they allow a common cache for multiple web applications and allow a cache to survive a web application restart. An in-memory cache really just accelerates cache hits even more so.
If you had a single instance of a web app but were running both in-memory and Redis, while you would still gain performance (from in-memory), it really isn't giving you much more than what in-memory by itself was besides caches surviving web application restarts. It's when you go to multiple instances of your application - your in-memory caches are only going to have whatever is needed by that specific server whereas Redis is going to have everything for all servers.
😄, Nice, But why you want to store cache in-memory ?, I think in-memory cache is not good for high traffic websites. If we store cache in same computer where application is hosted i think the application will not scale for large traffic. So Isn't it good to Make cache distributed in another computer using
Redis?An in memory cache hit is much faster than a redis hit. My boss' previous job used messaging (like MSMQ/RabbitMQ) to do the propagation, it got sub 10ms response times on full hot cache hits from what I recall.
Distributed in process in memory caching is a strategy to push high traffic web app response times beyond what a distributed out of process caching system like redis or couchbaae can give you.
It's basically applying the caching mechanisms of DNS and globally distributed CDNs in a web app.
can we decouple in memory cache like distributed cache to another computer ?
In-memory caching is great and is super fast but remember, this is about a multilayer cache where we can play to the strengths of multiple different types of cache. Redis is fast but in-memory in the same process will always be faster.
Distributed caches like Redis have two major benefits - they allow a common cache for multiple web applications and allow a cache to survive a web application restart. An in-memory cache really just accelerates cache hits even more so.
If you had a single instance of a web app but were running both in-memory and Redis, while you would still gain performance (from in-memory), it really isn't giving you much more than what in-memory by itself was besides caches surviving web application restarts. It's when you go to multiple instances of your application - your in-memory caches are only going to have whatever is needed by that specific server whereas Redis is going to have everything for all servers.
If your curious to a big site that does in-memory caching and Redis in .NET, it is what Stack Overflow does.