1

I'm using the .NET System.Runtime Memory cache to store transient resources in a WebAPI based REST service. The resource represents a "query". When a client issues a POST via HTTP we generate an ID and stick the query into the Cache. More details on the scenari can be found here.

When the client issues a GET, the resource is retrieved from the in-memory cache and the "query" is executed. This works fine in general but fails in a load balanced scenario since the client could hit instance 1 to POST the "query" and hit instance 2 to get the results.

I'm looking for options so as to enable this to work in a load balanced scenario. Writing to the "query" object to the database is not feasible both from a performance standpoint and also due to the transient nature of the query.

One possible solution is to use a distributed caching service such as "AppFabric" but I'd like to weight this against other options both in terms of performance and complexity of implementation.

Thoughts/guidance much appreciated.

TIA

Community
  • 1
  • 1
Abhijeet Patel
  • 6,562
  • 8
  • 50
  • 93

2 Answers2

3

Just to cover all the basis there are two ways to cache data:

InProc

In Proc caching store the data in the current application domain (within the application process). This works fine when your application is running on a single server, but in a load balanced scenario where more than one web server is involved this setup fails as you mention. The client's initial POST may be handled by one web server but next may be handled by another server who has no record of the client's first request.

Out Proc

OutProc caching allows you to store your session and application data outside of your application process, on a separate machine. ASP. NET allows 3 options for OutProc Caching:

  • StateServer

StakeServer allows you to cache data away from your web farm solving your initial problem but its performance is slow due to serialization and de-serialization. There are also reliability and scalability issues as you can only have a single StateServer which can become a single point of failure.

  • SQL Server

SQL Server provides session mode which allows you to store session data. As this stores the data in database there is a performance hit, but it does give you reliable and secure session management

  • Custom Providers

These are Custom Caching solutions that provide distributed caching. These solutions provide more functionality than what is available through StateServer and SQL Server.

AppFabric as you mentioned is one .NET Distributed Caching solution provided my Microsoft. It provides you with the basic distributed caching features but it is missing some key features such as Database Synchronization which allows you to synchronize you cached data with your database and "Hot Apply" where you can add or remove nodes from cache clusters without stopping the cache. AppFabric uses a master/slave architecture to organize its cache clusters, which is fine for most applications but it can have availability issues if the "Lead Nodes" go down.

NCache is another .NET Distributed Caching solution that provides a lot of features that are missing from AppFabric. It uses a Peer-to-Peer cluster architecture which provides a highly elastic cache with high availability. NCache also provides support for NHibernate for Object Relation Mapping. You can have a look at NCache at their website http://www.alachisoft.com/ncache/ . They offer NCache Express which is free to use.

Emma Jones
  • 46
  • 2
2

Do you know CacheCow? Very easy to setup and integrate on you current webapi project as message handler.
Using Redis implementation(built-in option) should be also centralized and very fast.

Crixo
  • 3,060
  • 1
  • 24
  • 32
  • Interesting.. I'll look into this. I know Redis provides a durable in memory store, just not quite sure whether it's distributed so that it can be shared across load balanced/scaled instances of a service – Abhijeet Patel Oct 09 '13 at 03:54