Performance difference between Azure Redis cache and In-role cache for outputcaching

Question

We are moving an asp.net site to Azure Web Role and Azure Sql Database. The site is using output cache and normal Cache[xxx] (i.e. HttpRuntime.Cache). These are now stored in the classic way in the web role instance memory.

The low hanging fruit is to first start using a distributed cache for output caching. I can use in-role cache, either as co-located or with a dedicated cache role, or Redis cache. Both have outputcache providers ready made.

Are there any performance differences between the two (thee with co-located/dedicated) cache methods?

One thing to consider is that will getting the page from Redis for every pageload on every server be faster or slower than composing the page from scratch one every server every 120 seconds but inbetween just getting it from local memory?

Which will scale better when we want to start caching our own data (i.e. pocos) in a distributed cache instead of HttpRuntime.Cache?

-Mathias

Panjandrum

Answer 1

Answering to your each question individually:

Are there any performance differences between the two (thee with co-located/dedicated) cache methods?

Definately co-located caching solution is faster than dedicated cache server, as in co-located/inproc solution request will be handled locally within the process where as dedicated cache solution will involve getting data over the network. However since data will be in-memory on cache server, getting will still be faster than getting from DB.

One thing to consider is that will getting the page from Redis for every pageload on every server be faster or slower than composing the page from scratch one every server every 120 seconds but inbetween just getting it from local memory?

It will depend on number of objects on page i.e. time taken to compose the page from scratch. Though getting from cache will involve network trip time but its mostly in fractions of a millisecond.

Which will scale better when we want to start caching our own data (i.e. pocos) in a distributed cache instead of HttpRuntime.Cache?

Since HttpRuntime.Cache is in-process caching, it is limited to single process's memory therefore it is not scalable. A distributed cache on the other hand is a scalable solution where you can always add more servers to increase cache space and throughput. Also out-proc nature of distributed cache solution makes it possible to access data cached by on application process to be used by any other process.

You can also look into NCache for Azure as a distributed caching solution. NCache is a native .Net distributed caching solution.

Following blog posts by Iqbal Khan will help you better understand the need of distributed cache for ASP.Net applications:

• Improve ASP.NET Performance in Microsoft Azure with Output Cache
• How to use a Distributed Cache for ASP.NET Output Cache

I hope this helps :-)

-Sameer

Xerosere

Thanks for the answer. I went ahead and started using the Azure Redis cache and the outputcacheprovider from StackExchange.Redis. Speed is of course lacking versus standard in-proc outputcache. Until Marc Gravell adds the 2-tier cache (local in-memory cache with a shared redis central cache, including pub/sub-based cache expiry notification etc) "promised" in the blog post announcing the Redis package there is a tradeoff. If I assume my app will use only a few web roles I benefit from in-proc outputcache but when I start using more instances I would befit from a distributed cache. – Patriciate

@MathiasR - I was looking for this question for a long time. Does 2 level caching helped or did you find any issue while using 2 level caching as in our cache the cache objects are bit large and getting them over network for individual users doesn't perform well during performance testing. – Horrid

@Horrid All mentioned cache methods except Redis cache are now obsolete. I would recommend using local in-memory cache, i.e. Cache[...] for Asp.Net or IMemoryCache for Asp.Net Core. Then always when setting something in cache also set it in Redis cache. And always when the cache has timed out first try to get it from Redis cache before generating the object again. – Patriciate