• NCache Express (FREE)
• Edition Comparison
• Performance Benchmark
• What's New in 4.1?
• Features
•  
• Intelligent Caching
• Dynamic Clustering
• Caching Topologies
• Caching App Block Integ
•  
• NCache Blogs
• Technical Whitepapers
• Related Articles
• Product Videos
•  
• NCache Forum
•  

NCache Clustering Topologies

NCache provides a rich set of clustering topologies to let you pick the one that suits your requirements best. Please note that NCache clustering is not the same as Windows Clustering. NCache forms its own cache-level cluster by using TCP protocol and can do so on any Windows XP, 2000, 2003, or Vista platform.

NCache forms a cluster among server nodes. These nodes actually cache data but the nature of this caching changes depending on what clustering topology you have selected. Below are all the different clustering topologies mentioned.

Local or Remote Clients

You can choose to run your application on cache server nodes or on remote client nodes. A server node is one that has the cache and participates in the cache cluster. And, a remote client node is any other node connected to one of the cache server nodes. In case of remote clients, you simply install NCache on your remote node and use the same NCache API to access the cache remotely. Your application is unaware of the fact that cache access is remote.

Here is how you would see this. Please note that you can remotely access all caching topologies in a transparent manner. Please note that each client node is connected to one server node. You can determine which node to connect either through a client configuration file or point to a load balancer that routes the connection to an appropriate server node. Additionally, if the server you're connected to goes down, the client node automatically connects to the next node in the server nodes list. And, this is initially specified in the configuration file but then is updated at run-time when new nodes join the cluster.

Replicated Cache

A clustered replicated cache consists of two or more cache servers forming a cluster. It allows all the data in the cache to be replicated in its entirety to all the nodes in the cluster. One benefit of replicated cache is that your cache exists in more than one place so if any server goes down, you don't lose any cache data. Another benefit is that all cache server nodes always find the data locally when your application does a GET operation. However, the drawback is that the cost of updates grows as you grow the cluster size because you have to update all nodes when you do an ADD, INSERT, or REMOVE operation. Another drawback is that the total size of the cache is limited to your memory size of any one node since all the cache is copied to all the nodes. Therefore, a replicated cache is suitable for small clusters, typically 2-6 server nodes. You can off course have a lot more client nodes and this is only a server node limitation. If your cluster needs to be larger then consider using one of the Partitioned Cache clusters.

Below is a diagram showing a replicated cluster.

1. Sticky Sessions: The problem with this approach is that it prevents the load balancer from truly balancing the load. All the requests are sent to their original server regardless of how much load is on that server. And, since not all sessions are of same length, this can easily overload one server and kill the performance of the entire application, even though there may be many server sitting almost idle.
2. Out-Of-Process Mode Session State Shared by All Servers: In this approach, you define "Out Proc" Session State on one server and then have all servers in the server-farm point to it. This has extreme scalability and availability issues. You're not able to scale up by adding more servers to the farm because one server is becoming the bottleneck, thereby defeating the entire purpose of server-farms. And, you've put yourself in an single-point-of-failure situation where one server going down would bring down the entire farm's sessions.
3. SQL Server Mode: In this approach, you keep all the session data in SQL Server. This approach has a great performance problem because not only are you accessing data from a remote server's hard disk, you're also competing with all your other database transactions. And, again, you're not really able to scale up your application by adding more servers to the server-farm because of your dependency on a single database server.

As compared to the above options, if you use NCache Session Management, you'll be able to achieve all the goals of using sessions and web-farms. They are:

1. Scalability: Because NCache Session State Management uses the underlying NCache Clustered Cache, you're able to scale up by adding more servers to the server-farm. NCache Clustered Cache provides a rich set of clustering topologies to meet your needs and grows almost linearly with your server-farm size.
2. Availability: Since NCache ensures that there is no single point of failure in clustered cache, you'll have high availability for your session data. Even if any one server goes down, you'll be able to fetch data from other servers without any problems.
3. Performance: One of the reasons for using Session State is to cache some data that is specific to a particular user but is needed over and over again during the user's session. And, since NCache Session Management is a high performance caching solution, you'll be able to improve your application's performance greatly with it.