Latency during failover scenario

This test simulates the impact on performance of Liberator failover. The Liberator was initially loaded with 1,000 clients and after about 12 seconds another 1,000 clients were logged in at once. This simulates the situation where the Liberator would be required to take over the client logins and their subscriptions from another Liberator that has suddenly failed. Two scenarios were tested, one where JMXTM monitoring was enabled, and one where it was not.

In both scenarios, at the point of the failover the update message latency rapidly increases as the Liberator handles the sudden rush of client login requests and sets up the clients' subscriptions. When JMX is not enabled, after about two seconds the Liberator completes the login processing and message latency drops back to the previous steady state level. When JMX is enabled, the failover imposes a greater processing load, so the latency increase lasts a second longer and the peak latency increase is rather higher.

Liberator version:	4.4
Number of DataSources (= number of DataSource threads in Liberator):	3
Number of Liberator session threads configured:	3
Number of Clients:	1,000 then 2,000
Number of DataSource objects available:	20,000 objects
Each client subscribes (at random) to:	100 objects
Update rate on each object subscribed to:	1 update/sec
Message Content for each update:	5 fields: One field of 13 characters (timestamp) Four fields of 3 characters each Total 25 bytes of update data
Bytes/second delivered to each client:	2,500 bytes/sec
Liberator burst-max Setting:	0.5 sec