First Objective Performance data for CEP
This week STAC (the Securities Technology Analysis Center) published a report measuring the performance of the Aleri CEP engine running an order book aggregation model on a Sun Server (running Solaris 10) with the Intel Caneland chip set. While this may only represent a single data point (or set of data points actually) in characterising the performance of an event processor, it’s the first time that anyone has published objective, verifiable performance numbers. In a field with a lot of talk about performance - both throughput and latency - STAC is providing a useful service by cutting through the marketing hype put out by various vendors (yes, including ourselves) to provide a level of transparency. Longer term, we expect that there will be industry-standard benchmarks that can serve as a tool to compare products. Aleri is a member of the STAC Benchmark Council and an active participant in the working group that is in the process of working toward the definition and agreement of such standards.In the mean time, the report published this week provides a level of transparency that has previously been missing.
Now this report doesn’t provide comparative data across products. And it only measures performance in a certain context - in this case order book aggregation. In fact, we didn’t choose to do the testing with a model that would show eye-popping throughput numbers, but rather chose to measure a use-case we are seeing in the field, where the numbers would be useful to people. In this case it shows throughput more than sufficient to consolidate the equity market with the highest traffic - the U.S. market - while maintaining a low latency profile. Other models (i.e. different data types and business logic) will display very different performance characteristics - some faster, some slower.
As my last blog post talked about, different applications have very different performance requirements. Some need very high throughput, some need very low latency, some need both, some don’t need either. I would characterize this use case as being very latency sensitive, demanding lowest possible latency, while having a mid to high throughput requirement (up to 150,000 messages per second, compared to some uses cases that are only dealing with 10’s or 100’s per second, and others that climb up to or even beyond a million per second - though the latter are relatively rare).
Bottom line, we were pleased to have the opportunity to work with STAC, Sun and Intel to get this report published and hope that people find it useful.

