1,000,000 updates per second?

Question

How could you configure a coherence cluster to handle processing a million stock quotes per sec? The datafeed could be configured as a single app spewing out all 1,000,000/sec or it could be many apps producing proportionately fewer ticks/sec but in any case it's going to total a million/sec. Fractions of the feed spread among multiple physical servers sounds smartest. The quote Map.Entry would probably have a Key of String (or char[] if that's more efficient - i know the max length). The Value would be a price and a size so maybe just those two elements byte[]{Float,Integer} or a java object with Float and Integer member variables. I'd want to trigger actions based on market conditions when the planets align just right so I'm not simply ignoring these values or pub/sub'ing them out to client apps, I'm evaluating many of them simultaneously and using them as event triggers. Is something like that remotely possible? On how much hardware?
Thanks,
Andrew

Answer 1

Andrew,
Using partitioning, Coherence can handle 1 million updates per second, but the big question is how many updates per second do you need on the hottest instrument at the hottest time?
The other question is related to "the planets lining up", because that may imply a global view of the market, which becomes more difficult in a partitioned system.
To provide a high rate of change to data in a partitioned system, the data providers (those with a large amount of data or a high rate of change) should be in the cluster (not coming in over *Extend) to eliminate one hop. To avoid blocking on the tick update from the data provider, it should locally enqueue the update. The queue servicer (a separate thread) should either coalesce whatever ticks are in the queue into a single putAll(), or if every tick needs to be recorded (i.e. all three ticks in the queue like "change to 3.5", "change to 3.55", "change to 3.6" have to be published, instead of just the latest "change to 3.6") then it would batch up everything in the queue until it hits an item that it already has in its batch, and then do a putAll().
The use of that async publishing mode is what allows for the much higher throughput, particularly when a data provider is producing a huge number of ticks in a given period of time. You can make it even smoother (e.g. avoid outliers caused by some servers being slower) by having more local queues+services (partitioned by Coherence partition, or at the extreme by instrument). You can determine the Coherence partition using the KeyPartitioningStrategy returned from the PartitionedService for the ticks cache.
Peace,
Cameron Purdy | Oracle Coherence
http://coherence.oracle.com/