Alachisoft.com
Download NCache Now!
Contact Us

+1 (925) 236-3830 sales@alachisoft.com

support@alachisoft.com

Live Chat

Performance and Linear Scalability - TayzGrid

This document describes the performance results of TayzGrid in a distributed environment. Please note that these tests were conducted in a QA environment and not in a professional performance testing lab. This means that you're likely to get better performance than this in your production environment.

Testing Configuration

Operating System: Windows 2008 Server
Architecture: Intel Pentium 4 or later
Number of processors: 2 dual-core processors
Memory: 8GB in each server
Network speed: Two 1-Gbit NICs
Client Configuration: Remote clients accessing cache cluster in a LAN. Number of clients increased until max load achieved for the given cache cluster size.
Data size: A string key + 1KB of data

Mirrored Cache Performance

Mirrored Cache is a 2-node active/passive data grid cluster. All clients connect to the active node and do their read-write operations against it. And, all updates are asynchronously applies to the passive mirrored node.


Mirrored Cache Benchmarks

Please note that Mirrored Cache can only have two data grid servers. Therefore, although it provides excellent performance for both reference and transactional data usage, it does not scale beyond a 2 server cluster. You can use other topologies if you want to scale.

Replicated Cache Performance

Replicated cache is good for reference data use. This is because it scale out really nicely for read-performance but the write-performance actually drops as you grow the data grid cluster (as you'll see in the benchmark results).

Replicated cache copies all the data to every data grid server in the cluster. This means that the storage capacity also does not grow when you add more data grid servers to the cluster.


Replicated Cache Benchmarks

As you can see, the read-performance keeps growing by 26000 reads per second as you add more data grid servers. But, write-performance drops quite rapidly as you grow data grid cluster. That is why we do not recommend more than 2 data grid servers in a cluster for Replicated Cache because growing the data grid cluster does not gain you anything. There are other topologies (Partitioned and Partition-Replica Cache) that are much better for scaling when it comes to write-performance.

Partitioned Cache Performance

Partitioned cache is an extremely scalable data grid for both read-performance and write-performance. Not only does it scale the transaction capacity well (reads and writes), it also grows the storage capacity as you add more servers to your data grid cluster.

The only drawback of this topology is that no replication of data is done. So, if any server goes down, you lose one partition of the data grid and hence a chunk of the data. But, this may not be an issue if you're using this data grid for application data where there is a master database. You can always fetch that data from the database and rebuild the data grid. There will however be a performance drop while you're doing this.


Partitioned Cache Benchmarks

As you can see, the write-performance is actually slightly better than read-performance but both reads and writes are scaling out in a fairly linear fashion.

Partitioned-Replica Cache Performance

Partitioned-Replica cache is a hybrid between replicated and partitioned caches. The data grid still has partitioning but each partition also has a replica on a different data grid server. This means that if any data grid server goes down and its partition is lost, the replica of that partition becomes active and starts serving the clients without any interruptions.

As a result, you get extreme scalability due to partitioning but also reliability through replication of the partitions.


Partitioned Replica Benchmarks

As you can see, the read-performance is faster than write-performance. This is because all writes are also replicating data to the replicas. But, this replication is much faster than Replicated Cache because it is asynchronous and also because the replica is passive and therefore no sequence-based synchronization is needed like it is in Replicated Cache.

The write-performance also scales in a linear fashion and gives you extremely fast performance.

Partition-Replica (Sync-Replication) Performance

Partition-Replica Cache also provides a sync-replication option in which all updates are made synchronously to both the active partition and its replica (meaning the client application waits until both are updated successfully). This ensures that there is no chance of any data loss in case of the partition going down abruptly which can happen in the async-replication.

However, as a result of this sync-replication, the update performance is not as fast as the async-replication but it is still much faster than Replicated Cache and more important you can scale it in a linear fashion by adding more data grid servers to the cluster. Below are the benchmarks:


Partitioned-Replica Sync Benchmarks

As you can see, the read performance is as fast as the asyn-replication but the write-performance is much slower. But, it still scales in a linear fashion. Also, please note that 1-node benchmarks are not included here because there is not replication being done there.

What to Do Next?