This is an extract of JBoss performance tuning book (for reading the full chapter download it here).
By using buddy replication, sessions are replicated to a configurable number of backup servers in the cluster (also called buddies), rather than to all servers in the cluster. If a user fails over from the server that is hosting his or her session, the session data is transferred to the new server from one of the backup buddies.
Buddy replication provides the following benefits:
- Reduced memory usage
- Reduced CPU utilization
- Reduced network transmission
The reason behind this large set of advantages is that each server only needs to store in its memory the sessions it is hosting as well as those of the servers for which it is acting as a backup. Thus, less memory required to store data, less CPU to elaborate bits to Java translations, and less data to transmit.
For example, in an 8-node cluster with each server configured to have one buddy, a server would just need to store 2 sessions instead of 8. That's just one fourth of the memory required with total replication.
In the following picture, you can see an example of a cluster confi gured for buddy replication:
Here, each node contains a cache of its session data and a backup of another node.
For example, node A contains its session data and a backup of node E. Its data is in turn replicated to node B and so on.
In case of failure of node A, its data moves to node B which becomes the owner of both A and B data, plus the backup of node E. Node B in turn replicates (A + B) data to node C.
In order to configure your SFSB sessions or HttpSessions to use buddy replication you have just to set to the property enabled of the bean BuddyReplicationConfig inside the <server>/deploy/cluster/jboss-cache-manager.sar/META-INF/jboss-cache-manager-jboss-beans.xml configuration file, as shown in the next code fragment:
In the following test, we are comparing the throughput of a 5-node clustered web application which uses buddy replication against one which replicates data across all members of the cluster.
In this benchmark, switching on buddy replication improved the application throughput of about 30%. No doubt that by using buddy replication there's a high potential for scaling because memory/CPU/network usage per node does not increase linearly as new nodes are added.