Some of the very basic needs for .NET applications to stay competitive in today’s market are to be extremely responsive and scalable. The bottleneck in the way of achieving these benchmarks is your relational database.
This is a two fold bottleneck, first the reads from disk are very inefficient and time consuming. Secondly, you cannot scale out the database tier by adding more database servers. Whereas if you have a .NET distributed cache, it provides fast data access because it is in-memory and it can also scale linearly the same way your application tier does.
NCache is a .NET distributed cache that provides performance and scalability for your applications. It comes with a rich set of features including but not limited to cache elasticity, high availability, data replication, seamless integration with existing technologies and ease of management. Lets just focus on performance and scalability, as identified in the beginning. These are two fundamental metrics needed by .NET applications to survive in today’s world. Let’s see how NCache is positioned to cater for both.
NCache gets its performance edge over relational database because it keeps its data in memory and not on the disk. The performance boost over relational databases is ten times or higher depending on your hardware and .NET cache positioning in the network. For example if you deploy NCache as a local in-proc cache in your environment, the data access becomes lightning fast.
And the way NCache provides scalability is by allowing you to add more cache servers when your transaction load grows. So, if you see that your application getting overwhelmed by transaction load, just add a new cache server at run-time. You don’t even have to stop your application for this. With this new cache server added, you have the ability to serve more requests and all of this happens transparent to the user. Now, that’s what I mean by scalability.
There are a number of caching topologies that NCache offers to choose from depending on your specific need. The caching topology defines how your data is stored and the way individual cache servers in the cluster interact with one another. For example, Partitioned Cache, Partition-Replica Cache, Replicated Cache, and Mirrored Cache are the caching topologies.
If your primary concern with your .NET cache is scalability and not reliability you can use the ‘Partitioned Cache’ topology. On the other hand, if your primary focus is to get reliability and not scalability you should go for the ‘Replicated Cache’ topology. The ‘Partition-Replica Cache’ is the combination of both of these and gives you the best of both worlds. It provides you with reliability and scalability at the same time with some trade offs.
I would like to conclude by saying that if you want your application to be at par with the growing needs of performance and scalability, .NET distributed cache is the way to go.