Why use shared cache?
There is no more efficient way to increase the scalable performance of applications then the use caching to unload deeper layers.
>> Shared Cache>> Shared Cache Topology
Distributed Caching - partitioned
- your requirement: extreme scalability
- our solution: shared-nothing architecture, automatically partition data across all cluster members
- your result: linear scalability. by partitioning the data evenly, the port-to-port throughput (the maximum amount of work that can be performed by each server) remains constant as servers are added, up to the extent of the switched fabric.
- your benefits:
- 1 - Partitioned: the size of the cache and the processing power available grow linearly with the size of the cluster.
- 2 - Load Balanced: the responsibility for managing the data is automatically load-balanced across the cluster.
- 3 - Point-to-Point: the communication for the partitioned cache is all point-to-point enabling linear scalability.
- limits: as the amount of members in your cluster ram.
- your uses: any ram size caches, scaling with the size of the cluster.
Replicated Caching
- your requirement: extreme Performance
- our solution: All data will be fully replicated to all cluster members. Through the usage of fully replicated data to all members of the cluster will achive your zero latency access and extreme performance requirements.
- your result: Through zero latency access. Since the data is replicated to each member, it is available in each member without network latency and without waiting time.
- your benefits: This provides the best / possible speed for accessing data in your cache
- limits:
- Cost per update: Updating a replicated cache requires pushing the new version of the data to all other cluster members, which will limit scalability if there are a high frequency of updated per member
- Cost per entry: the data is replicated to every cluster member, so CLR heap space is used on each member, which will impact performance for large caches
Single Instance Caching
- your requirement: build a scalable system architecture
- our solution: There are no limitations to grow as your system grows
- your result: Linear scalability by partitioning the data on your indeXus.Net Shared Cache instance, the port-to-port throughput (the maximum amount of work that can be performed by each server) remains constant as servers are added, up to the extent of the switched fabric.
- your benefits: This provides the best / possible speed for accessing data in your cache.
While you grow, it will not require any refactoring since everything happens over configuration
- limits: The size of available RAM
