These two tests used a different test set up, where a single Liberator instance ran on a Dell PowerEdge server (Test Machine 1 as detailed in Test hardware). In these tests a much larger pool of objects was available for clients to subscribe to. Therefore, much higher back end update rates are seen and higher client update rates are tested. These tests only plot the message latency and not the server CPU usage.

Very high update rates

Very high update rates

In this test of very high update rates clients subscribe to 100 objects out of a pool of 20,000 objects, each updating once per second.

The red plot (solid line) shows Liberator running with a burst-max (batching) configuration parameter setting of 0.5 seconds. As the number of clients subscribing increases the message latency rises very slowly from about 250 milliseconds. The Liberator can handle over 10,000 clients (which is 1 million object updates per second delivered to the clients), with the message latency still below 300 milliseconds.

The green plot (dashed line) shows Liberator with the same subscription and update profile, but with the burst-max setting reduced to 0.1 seconds. By reducing burst-max, the average message latency has been substantially reduced to just over 50 milliseconds. This is at the expense of the number of subscribing clients (and hence the total overall message rate); the Liberator can now only handle about 6,300 clients (which is 630,000 object updates per second delivered to the clients).

Extreme update rates

Extreme update rates

In this test of extremely high update rates 500 objects are subscribed to by clients, choosing randomly from 40,000 objects each updating once per second. This means a back end update rate of 40,000 updates/sec and each client receiving 500 updates/sec. With 100ms batching configured latency is expected to be 50ms or more, the plot showing latency increases above this expected floor as the users increase.