Liberator Performance
A common fear with Comet solutions is the extra resources needed to handle possibly thousands of concurrent users all receiving streaming data. Direct comparisons cannot usually be made between Comet applications and non Comet applications, since they are achieving things in a totally different way. However, if you are changing a static site into a streaming Comet site then resources and performance will play a part in the decision process.
One of Liberator's main strengths is its performance. It can handle up to 30,000 concurrent users on a single server, all receiving data. With 10,000 concurrent users Liberator is able to stream 100 updates/sec to each of those 10,000 users, that makes a total of 1 million updates/sec being streamed to users.
Latency is often a concern with Comet solutions. Liberator has various configuration options to tune performance, and latency is often a trade off made. The results below show this in more detail.
Benchmark Results
The following results are taken from recent benchmark tests performed on Liberator. The tests are designed to try and simulate real usage often seen in financial applications, but also applies to any application where clients are subscribed to a relatively small subset of the available data.
All three tests use a data set of 1000 subjects, each one updating once every two seconds. Each client connects and subscribes to a random selection from those 1000 subjects. The number of subscriptions each client makes is fixed for each test, e.g. in the first test each client subscribes to just 2 subjects out of the total 1000. Since the subjects are updating once every two seconds, in the first test each client is receiving one update per second. Therefore, we have a known update rate being sent out to the clients. The update rate being received by Liberator depends on the number of clients, since they choose randomly out of the 1000 objects, as more clients subscribe the more of the 1000 objects are feed into Liberator.
The number of clients is then increased until a limit, such as unsatisfactory latency, is reached. Latency and server CPU are measured throughout the test.
Low update rates
This test shows a very large number of users receiving a fairly low update rate with a very low latency and low CPU utilization.
(Click for full size version)
Medium update rates
In this test the number of subscriptions each client makes is increased, which increases the update rate to 10 messages per second to each client. The results show that a very high number of users is still achievable. We can see that after about 12,000 clients the latency starts to increase more.
(Click for full size version)
High update rates
This test increases the update rate to 50 messages per second to each client. A lot of Comet applications would never need anything like this level of updates, but many financial applications do, and often even higher update rates.
We can still see decent performance up to around 10,000 clients. Understandably, latency is higher than in previous tests. It is worth pointing out that at the 10,000 client mark Liberator is sending out 500,000 messages per second in total, which is 29MBytes/sec.
(Click for full size version)
Conclusion
These results show a sample of results from benchmarking Liberator. There are many variables involved in performing benchmark tests and therefore results can vary depending on setup, requirements and implementation of the tests.
More details can be found in the document Benchmarking Caplin Liberator (pdf) or an HTML version. This document shows some more test scenarios with much higher update rates.
References
© Copyright Caplin Systems Ltd 2002-2009. All rights reserved.