Developer Champion
Martin Fowler has written a really good article describing not only the Disruptor, but also how it fits into the architecture at LMAX. This gives some of the context that has been missing so far, but the most frequently asked question is still "What is the Disruptor?".
I'm working up to answering that. I'm currently on question number two: "Why is it so fast?".
Continue reading "Dissecting the Disruptor: Why it’s so fast (part one) – Locks Are Bad"
So now I've covered the ring buffer itself, reading from it and writing to it.
Logically the next thing to do is to wire everything up together.
I talked about multiple producers - they have the producer barrier to keep them in order and under control. I've talked about consumers in a simple situation. Multiple consumers can get a little more involved. We've done some clever stuff to allow the consumers to be dependent on each other and the ring buffer. Like a lot of applications, we have a pipeline of things that need to happen before we can actually get on with the business logic - for example, we need to make sure the messages have been journalled to disk before we can do anything.
The Disruptor paper and the performance tests cover some basic configurations that you might want. I'm going to go over the most interesting one, mostly because I needed the practice with the graphics tablet.
Continue reading "Dissecting the Disruptor: Wiring up the dependencies"
This is the missing piece in the end-to-end view of the Disruptor. Brace yourselves, it's quite long. But I decided to keep it in a single blog so you could have the context in one place.
The important areas are: not wrapping the ring; informing the consumers; batching for producers; and how multiple producers work.
Continue reading "Dissecting the Disruptor: Writing to the ring buffer"
The next in the series of understanding the Disruptor pattern developed at LMAX.
After the last post we all understand ring buffers and how awesome they are. Unfortunately for you, I have not said anything about how to actually populate them or read from them when you're using the Disruptor.
Continue reading "Dissecting the Disruptor: How do I read from the ring buffer?"
Recently we open sourced the LMAX Disruptor, the key to what makes our exchange so fast. Why did we open source it? Well, we've realised that conventional wisdom around high performance programming is... a bit wrong. We've come up with a better, faster way to share data between threads, and it would be selfish not to share it with the world. Plus it makes us look dead clever.
On the site you can download a technical article explaining what the Disruptor is and why it's so clever and fast. I even get a writing credit on it, which is gratifying when all I really did is insert commas and re-phrase sentences I didn't understand.
However, I find the whole thing a bit much to digest all at once, so I'm going to explain it in smaller pieces, as suits my NADD audience.
First up - the ring buffer. Initially I was under the impression the Disruptor was just the ring buffer. But I've come to realise that while this data structure is at the heart of the pattern, the clever bit about the Disruptor is controlling access to it.
Continue reading "Dissecting the Disruptor: What’s so special about a ring buffer?"
On Wednesday I tagged along to the STAC London Summit to provide backup for Mike, who was on the "The Future of Messaging Middleware" panel.
The panel consisted of two messaging providers, one hardware (Solace Systems) and one software (29West/Informatica), and two "users", Citihub and LMAX. Obviously both providers were arguing that theirs was the best solution. But what I found interesting is that I came away with the impression that everyone was really on the same side - everyone wants to use or to provide the best system, but there are different approaches. Which one you adopt is likely to be influenced by how your team work and the hardware you have (or can obtain).
I'm honoured to now be listed on three aggregated blog feeds:
The pressure's on to try and write useful stuff. Oh OK, I'll settle for "entertaining".
I have been struggling with .NET. Actually, I have been fighting pitched battles with it.
All I want to do is take our existing Java client example code and write an equivalent in C#. Easy, right?
Turns out writing the actual C# is relatively straightforward. Putting to one side the question of writing optimal code (these are very basic samples after all), to get the examples to compile and run was a simple process:
I attended TradeTech last week, an annual event about Equities and Derivatives trading. I assumed from the title that there would be a reasonable focus on technology, but I found it was more “Trade” and less “Tech”.
Continue reading "TradeTech 2011 – Not like a developer conference"
At LMAX we adopted Google Web Toolkit pretty early on. One of the motivations for using it was so we only had to worry about recruiting Java guys, and then we could all work on every part of the application including the web UI. Sure, you can learn a bunch of different skills if you want to, but it reduced context-switching and kept the skill set we were hiring for to a nice short list.
The problem is that GWT does a very nice job of pretending to be Java whilst actually compiling down to HTML and JavaScript. If you don't have some understanding of the end result (the DOM the browser is going to be rendering) it's going to be hard to get the performance you need from a low-latency trading application.
My number one bug-bear with GWT is VerticalPanel. To the uninitiated developer, this seems like the sort of thing that will be useful everywhere. You often want stuff stacked on top of each other - think menus, lists, the layout of a dialog. What is not obvious is that it uses tables for layout under the covers, and I've mentioned in the past that Tables Should Not Be Used For Layout.
A much less obvious way of getting the same result with (usually) no extra effort is to use FlowPanel. This is rendered as a div, and most of the time the elements that get inserted into it will render in a vertical stack.
VerticalPanel panel = new VerticalPanel();
panel.add(/* your widget */);
panel.add(/* your second widget */);<table>
<tbody>
<tr>
<td>
<!– your widget here –>
</td>
<tr>
<tr>
<td>
<!– your second widget here –>
</td>
<tr>
</tbody>
<table>FlowPanel panel = new FlowPanel();
panel.add(/* your widget */);
panel.add(/* your second widget */);<div>
<!– your widget here –>
<!– your second widget here –>
</div>You can see that the DOM generated for a very similar-looking 3 lines of code is much much smaller for FlowPanel.
Right, but we're only talking about a few more elements, and browsers are pretty smart about optimising these things. Right?
Maybe. But if you use VerticalPanel for all your containers, for every box which needs to be a slightly different colour, for every place you want to change the alignment slightly, things get very big very fast. This is an example of real code from an early prototype, where we had several nested panels (not unheard of if you've got a complex dialog box with lots of elements in it. Like, say, a deal ticket). And I've stripped out a lot of the table attributes that made this even more heinous:
<table>
<tbody>
<tr>
<td align="left”>
<table id="panel1”>
<tbody>
<tr>
<td align="left” style="vertical-align: top;">
<table class="orders-input”>
<tbody>
<tr>
<td align="left”>
<table class="row”>
<tbody>
<tr>
<td align="left”>
<table id="container”>
<tbody>
<tr>
<table id="panel2”>
<tbody>
<tr>
<td align="left”>
<table class="controls”>
<tbody>
<tr>
<td align="left”>
<!– widget –>For every table element and associated elements (tbody, tr, td), you would get a single div element instead if you simply replace every instance of VerticalPanel in this stack with a FlowPanel.
<div>
<div id="panel1”>
<div class="orders-input”>
<div class="row”>
<div id="container”>
<div id="panel2”>
<div class="controls”>
<!– widget –>See? Much nicer.
This is exactly what we did do, and we saw a noticeable speed improvement across all browsers - noticeable to a real user, not just some millisecond improvement on a performance test. Mind you, users' brains are amazing things and your system has to react in less than 0.1 seconds for a user to perceive it as instantaneous. So even in a browser, every millisecond counts.
In addition to improved performance, you get a nice bonus: now the layout is no longer controlled by tables, you can really easily shove stuff around and make things look pretty with the clever use of CSS. If you're really lucky, you can chuck that stuff over to your designers and not have to do another GWT compile when someone wants to move things 3 pixels to the left. Which they will.