The LMAX Architecture. LMAX is a new retail financial trading platform. As a result it has to process many trades with low latency. The system is built on the JVM platform and centers on a Business Logic Processor that can handle 6 million orders per second on a single thread. The Business Logic Processor runs entirely in-memory using event sourcing. The Business Logic Processor is surrounded by Disruptors - a concurrency component that implements a network of queues that operate without needing locks. During the design process the team concluded that recent directions in high-performance concurrency models using queues are fundamentally at odds with modern CPU design.
Over the last few years we keep hearing that "the free lunch is over"[1] - we can't expect increases in individual CPU speed. So I was fascinated to hear about a talk at QCon London in March last year from LMAX. Overall Structure Figure 1: LMAX's architecture in three blobs At a top level, the architecture has three parts Business Logic Processor. The Secret to 10 Million Concurrent Connections -The Kernel is the Problem, Not the Solution.
Now that we have the C10K concurrent connection problem licked, how do we level up and support 10 million concurrent connections? Impossible you say. Nope, systems right now are delivering 10 million concurrent connections using techniques that are as radical as they may be unfamiliar. To learn how it’s done we turn to Robert Graham, CEO of Errata Security, and his absolutely fantastic talk at Shmoocon 2013 called C10M Defending The Internet At Scale. Robert has a brilliant way of framing the problem that I’ve never heard of before. He starts with a little bit of history, relating how Unix wasn’t originally designed to be a general server OS, it was designed to be a control system for a telephone network. It was the telephone network that actually transported the data so there was a clean separation between the control plane and the data plane. Which is why he says the key is to understand: The kernel isn’t the solution. Which means: Don’t let the kernel do all the heavy lifting.
Summary.
Axel Fontaine: Optional Dependency Strategies for Java Libraries. In software, contrary to common belief, . As you gradually accumulate code, little by little the pain sets in. The complexity increases. It gets harder to understand. And eventually, quality suffers. With each dependency you add, you pull in more code, more APIs to learn and more potential bugs. Transitive dependencies take this problem to 11. And yet, dependencies are a necessary evil. Special case: Libraries and Frameworks A library or framework in broad general use (like Flyway ) usually supports a wide range of scenarios for a very diverse set of users. 10+ Jdbc Drivers Spring Jdbc OSGi (Equinox) JBoss VFS v2 JBoss VFS v3 Ant Maven Nobody in their right mind would be keen on pulling all these dependencies in just to use the subset they need.
How do we solve this? The answer lies in . There are for dealing with optional dependencies: Create a separate module which depends on the base module and the optional dependency Create a module per optional dependency which the base module depends on. UltraViolet. A light UML editor for JMatter. Module-System Requirements — DRAFT 12. Refactor, define, enforce architecture for Java, .Net, C/C++ and more with Structure101 and Restructure101.