Agenda• Introduction• What is LMAX?• Problems they were trying to solve• Concurrent Programming• Locks• Queues• The Disruptor Pattern• LMAX Architecture• Live Demo• Q&A
LMAX• London Multi-Asset eXchange• Build the fastest trading platform in the world• Retail platform, it allows anyone to trade withoutgoing through a broker• They have an order matching engine, real-time riskmanagement, in-memory transaction processingsystem, etc.
Problems to Solve• Extreme transaction processing (XTP)• High-throughput, low-latency / predictablelatency• Scale to potentially millions of users
They tried…• RDBMS• JEE• SEDA• Actors… And none of the above offered the predictable lowlatency they were after
Concurrent Programming• Protect access to contended resources (mutualexclusion)• Make the results public in the right order(visibility of changes)• Locks (standard synchronized blocks in Java)• Atomic / CAS Instructions – boils down tomachine instructions
Locks? No…• Context switch to the OS kernel for arbitration(even worse in a virtualized environment).• It’s taking your thread quantum away and mightdecide to do something else…• When your thread is scheduled to run again itmight end up on another core and it will have toreload all the execution context.
Queues? No…• Either full or empty, mostly empty in a wellrunning system, cannot resize easily• 1 Producer, 1 Consumer… 2 threads writing intothe queue• High contention for head and tail• Create garbage (put and take) so GC has a lot ofcleanup to do, impacts latency
In production…• 6 million TPS (3Ghz dual-socket quad coreIntel on a Dell Server 32 Gb of RAM) in2011…• Single threaded, in memory• 20 million items on the input ring buffer• 4 million items the output ring buffer
Key Takeaways• Mechanical Sympathy• Keep the working sets in memory• Write clean compact code• Invest in modeling your domain (SRP – oneclass one thing, one method one thing, etc.)• Take the right approach to concurrency