Don't Repeat Others and The Disruptor

[Michael Barker]

Hi,

Given the recent discussion on concurrency and performance in the Scala Persistence thread, I thought some of the readers may be interested in an open source project that some colleagues and I launched recently: http://code.google.com/p/disruptor/.  It's a concurrent structure used at the heart of a high performance financial exchange that we've been building over the past 3 years (in Java of course).  I also chatted to a few people at the round-up about the work we were doing.

It falls squarely into the exceptional case of Dick's "Don't Repeat Yourself or Others" rule, so we've thrown it out there in open source form.  In its simplest form it's an alternative to a queue, i.e. a structure to move data between threads.  We've also added a couple of classes that give it the feel of an actor framework (not truly actors, as it's 1 consumer per thread).  It's pretty fast, over 3 orders of magnitude lower latency when compared to ArrayBlockingQueue.  For those that are interested in the gory details, there's a technical paper on the Google code site that does a very deep dive into the implementation and describes the results of our performance tests.

Mike.

[ne...@swingler.ch]

Hi Mike,

thanks for that. The infoq lmax presentation is highly recommended for
anybody interested in concurrency.

You preallocate all the message objects in the queue. Did you
investigate implementing your queues as a byte stream and using some
kind of serialization on your message objects?

- Neil

On Thu, 23 Jun 2011 22:51:49 -0700 (PDT), Michael Barker wrote:
> Hi,
>
> Given the recent discussion on concurrency and performance in the
> Scala Persistence thread, I thought some of the readers may be
> interested in an open source project that some colleagues and I

> launched recently: http://code.google.com/p/disruptor/ [1]. It's a

> concurrent structure used at the heart of a high performance
> financial
> exchange that we've been building over the past 3 years (in Java of
> course). I also chatted to a few people at the round-up about the
> work
> we were doing.
>
> It falls squarely into the exceptional case of Dick's "Don't Repeat
> Yourself or Others" rule, so we've thrown it out there in open source
> form. In its simplest form it's an alternative to a queue, i.e. a
> structure to move data between threads. We've also added a couple of
> classes that give it the feel of an actor framework (not truly
> actors,
> as it's 1 consumer per thread). It's pretty fast, over 3 orders of
> magnitude lower latency when compared to ArrayBlockingQueue. For
> those
> that are interested in the gory details, there's a technical paper on
> the Google code site that does a very deep dive into the
> implementation and describes the results of our performance tests.
>
> Mike.
>

> --
> You received this message because you are subscribed to the Google
> Groups "The Java Posse" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/javaposse/-/DynCqAEpU0gJ [2].
> To post to this group, send email to java...@googlegroups.com.
> To unsubscribe from this group, send email to
> javaposse+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/javaposse?hl=en.
>
>
> Links:
> ------
> [1] http://code.google.com/p/disruptor/
> [2] https://groups.google.com/d/msg/javaposse/-/DynCqAEpU0gJ

[Michael Barker]

 You preallocate all the message objects in the queue. Did you
 investigate implementing your queues as a byte stream and using some
 kind of serialization on your message objects?

That's almost exactly what we've done.  The object in the ring buffer is a ByteBuffer which we copy/marshal into and out of, giving us an non-shared mutable state concurrency model.  We only have a single application thread per service and the thread transitions are to/from the threads responsible for network I/O.  So the service looks like: Network -> Ring Buffer -> Application -> Ring Buffer -> Network.  Very similar to the model used by Node.JS.

Mike.

[Matthew Farwell]

Hello,

Martin Fowler has published an article (http://martinfowler.com/articles/lmax.html) on the LMAX architecture, in case anyone is interested:

From the article:

--

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.

--

Cordialement,

Matthew.

2011/6/24 Michael Barker <mik...@gmail.com>

--

You received this message because you are subscribed to the Google Groups "The Java Posse" group.

To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/DynCqAEpU0gJ.

[Casper Bang]

> Martin Fowler has published an article (http://martinfowler.com/articles/lmax.html) on the LMAX architecture, in
> case anyone is interested:

Ohh it's LMAX, not Imax... and here I thought I had to jump the
presentation lacking an Imax projector!

[Michael Barker]

It's also available in Scala flavour:

https://github.com/jamie-allen/sdisruptor