Intro
high-performance, distributed memory object caching system, generic in nature, but intended to speeding up dynamic web and / or win applications by alleviating database load.
Release: release 2.0.3.270
General Overview
indeXus.Net Shared Cache is high performance distributed and replication cache system build for .Net cache and enterprise application running in server farms. indeXus.Net Shared Cache provides distributed replicated cache to minimize the load factor. It consists the usage of two or more servers in a farm. It's replicated all data within the cluster. The big plus is simple, you have all your cache nodes on all different servers. In case one of your servers get restarted, it will receive all nodes automatically from its parent. indeXus.Net Shared Cache uses 100% managed code which is written .Net C#.
Why you should consider to use shared cache?
There is no more efficient way to increase the scalable performance of applications then the use caching to unload deeper layers.
indeXus.Net Shared Cache Topologies
indeXus.Net Shared Cache provides a rich set of different scenarios to let you pick the option which suits your requirements. Connectivity between nodes happens on IP Layer 4 - Transport.
Distributed Caching - partitioned
- your requirement:
- 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:
- Partitioned: the size of the cache and the processing power available grow linearly with the size of the cluster.
- Load Balanced: the responsibility for managing the data is automatically load-balanced across the cluster.
- Point-to-Point: the communication for the partitioned cache is all point-to-point enabling linear scalability.
- the 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:
- 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
- the 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
- the limits:
- The size of available RAM
General Information
- The usage of indeXus.Net Shared Cache does NOT prevent you to go on and use System.Cache.
 link
|