HTTP Session Replication - Full Replication
This topic has not yet been written. The content below is from the topic description.
Full Replication As we stated in the introduction to HTTP session replication, full replication means that all sessions are replicated to all nodes. This may sound like an odd default, but when you consider that a lot of clusters are small, even many just being two nodes, its hard to justify a more complex setup as the default. If you have a two node cluster, then there will be no functional difference between full replication and buddy replication which we defined in the introduction to this section. If you have more than two nodes, that is when you need to consider other options, other than full replication. Even then, full replication may still meet yours needs, but it depends on how you use the HTTP session. Obviously, when talking about full replication, the overhead of the replication of every HTTP session will increase as you add nodes. How much will depend on several factors. Those factors are how often new sessions are created, and how often old sessions are removed. How often the data in the HTTP sessions changes, and how large the session is. As you can see, it becomes complex fairly quickly with determining whether full replication or whether our other replication option, buddy replication, is the right answer for your application. There is no substitute for knowing your applications usage pattern of the HTTP session. One last thought with full replication - if your HTTP session is even moderate in size, the amount of memory you use is the HTTP Session Size x Active sessions x Number of Nodes. This can easily explode with not only a large amount of memory across all the nodes, but also usage of memory just to hold the replicated session/ Not only that but there is a possibility that that session’s owner (client) is not actively running its requests on those other nodes. In summary, whether you should use the default configuration of full replication is really up to your particular workload. If you have multiple applications deployed at the same time, the complexity gets even higher, as you might have applications that behave quite differently between each other. In internal testing that we have done, full replication scales fine with two nodes - as you would expect - but scalability with HTTP sessions of between 4k and 16k, the scalability is not particularly good with between 3 and 10 nodes in the cluster. That testing was done with a gigabit ethernet network with jumbo frames enabled (9,000 byte MTU). Having said that, if you have a cluster larger than two nodes and you are doing HTTP session replication, then consider buddy replication as your starting point. Buddy