© Excellent backgrounds/Shutterstock.com
Java Magazin
Hochskalierbare Transaktionsplattformen mit dem LMAX Disruptor

Wenn RAM zu - langsam ist

Warum der herkömmliche Architekturansatz hochskalierbarer Transaktionsplattformen im Widerspruch zur Funktionsweise moderner Hardware steht, wird im folgenden Beitrag erläutert. Am Beispiel der London Multi Asset Exchange (LMAX) wird dargestellt, welches Transaktionsvolumen die Java Virtual Machine abwickeln kann, wenn man die ausgetretenen Pfade verlässt.

Eugen Seer, Sebastian Bohmann, Oliver Selinger


„The most amazing achievement of the ­computer software industry is its ­continuing cancellation of the steady and staggering gains made by the ­computer hardware ­industry.“

– Henry Petroski

Die LMAX ist ein von der englischen Financial Services Authority (FSA) zugelassenes multilaterales System für den Direkthandel von privaten und institutionellen Anlegern, kurz gesagt: eine offene Börse [1]. Als die LMAX vor einigen Jahren die Entwicklung ihrer Handelssoftware in Angriff nahm, waren folgende nicht funktionale Anforderungen zu erfüllen:

Vorhersagbare durchschnittliche Systemlatenz von unter einer Millisekunde, um das finanzielle Risiko wegen der Spreads (Unterschied zwischen Ankaufs- und Verkaufskurs) zu minimierenAbwicklung von Millionen Transaktionen pro ­SekundeHochverfügbarkeit und AusfallsicherheitVertretbare Betriebskosten

Die Analysen und Performancemessungen der involvierten Ingenieure ergaben, dass alle herkömmlichen Ansätze wie relationale Datenbanken, Java EE, Concurrent Queues oder Aktoren nicht in der Lage waren, das hohe Transaktionsaufkommen auch nur annähernd mit den angeforderten Werten für Durchsatz und Latenz abzuwickeln. Selbst bei weitgehender Vermeidung von I/O-Zugriffen verbrachten die Systeme bei steigender Last mehr Zeit mit der Administration der Nebenläufigkeit als mit der Ausführung der Geschäftslogik [2].

Der Grund lag darin, dass die vielen Threads kontinuierlich von unterschiedlichen Prozessorkernen aus auf dieselben Daten zugriffen. Weil diese Daten und deren Änderungen für alle Prozessorkerne sichtbar sein mussten, erfolgten diese Zugriffe an den Caches vorbei (man spricht hierbei von Cache Misses) direkt in das RAM. Dabei ist anzumerken, dass die Geschwindigkeit von RAM-Zugriffen sich seit vielen Jahren nicht entscheidend verbessert hat. Was sich jedoch deutlich weiterentwickelt hat, sind die Caches der Prozessorkerne. Diese sind erheblich schneller und durch die 64-Bit-Adressierung auch größer geworden.

Zusammengefasst nutzen herkömmliche nebenläufige Architekturansätze zwar vordergründig alle Prozessorkerne. Sie scheitern jedoch daran, dass auf moderner Hardware die durch sie verursachten Cache Misses und RAM-Zugriffe die Performance stark beeinträchtigen.

Concurrent Queues: trügerischer Komfort

Seit Java 5 sind Concurrent Queues ein beliebtes Mittel zur einfachen und komfortablen Kommunikation zwischen zwei oder mehreren Threads, vor allem im Vergleich zu systemnäheren Mechanismen wie beispielsweise Locks.

ContentionAls C...

Java Magazin
Hochskalierbare Transaktionsplattformen mit dem LMAX Disruptor

Wenn RAM zu - langsam ist

Warum der herkömmliche Architekturansatz hochskalierbarer Transaktionsplattformen im Widerspruch zur Funktionsweise moderner Hardware steht, wird im folgenden Beitrag erläutert. Am Beispiel der London Multi Asset Exchange (LMAX) wird dargestellt, welches Transaktionsvolumen die Java Virtual Machine abwickeln kann, wenn man die ausgetretenen Pfade verlässt.

Eugen Seer, Sebastian Bohmann, Oliver Selinger


„The most amazing achievement of the ­computer software industry is its ­continuing cancellation of the steady and staggering gains made by the ­computer hardware ­industry.“

– Henry Petroski

Die LMAX ist ein von der englischen Financial Services Authority (FSA) zugelassenes multilaterales System für den Direkthandel von privaten und institutionellen Anlegern, kurz gesagt: eine offene Börse [1]. Als die LMAX vor einigen Jahren die Entwicklung ihrer Handelssoftware in Angriff nahm, waren folgende nicht funktionale Anforderungen zu erfüllen:

Vorhersagbare durchschnittliche Systemlatenz von unter einer Millisekunde, um das finanzielle Risiko wegen der Spreads (Unterschied zwischen Ankaufs- und Verkaufskurs) zu minimierenAbwicklung von Millionen Transaktionen pro ­SekundeHochverfügbarkeit und AusfallsicherheitVertretbare Betriebskosten

Die Analysen und Performancemessungen der involvierten Ingenieure ergaben, dass alle herkömmlichen Ansätze wie relationale Datenbanken, Java EE, Concurrent Queues oder Aktoren nicht in der Lage waren, das hohe Transaktionsaufkommen auch nur annähernd mit den angeforderten Werten für Durchsatz und Latenz abzuwickeln. Selbst bei weitgehender Vermeidung von I/O-Zugriffen verbrachten die Systeme bei steigender Last mehr Zeit mit der Administration der Nebenläufigkeit als mit der Ausführung der Geschäftslogik [2].

Der Grund lag darin, dass die vielen Threads kontinuierlich von unterschiedlichen Prozessorkernen aus auf dieselben Daten zugriffen. Weil diese Daten und deren Änderungen für alle Prozessorkerne sichtbar sein mussten, erfolgten diese Zugriffe an den Caches vorbei (man spricht hierbei von Cache Misses) direkt in das RAM. Dabei ist anzumerken, dass die Geschwindigkeit von RAM-Zugriffen sich seit vielen Jahren nicht entscheidend verbessert hat. Was sich jedoch deutlich weiterentwickelt hat, sind die Caches der Prozessorkerne. Diese sind erheblich schneller und durch die 64-Bit-Adressierung auch größer geworden.

Zusammengefasst nutzen herkömmliche nebenläufige Architekturansätze zwar vordergründig alle Prozessorkerne. Sie scheitern jedoch daran, dass auf moderner Hardware die durch sie verursachten Cache Misses und RAM-Zugriffe die Performance stark beeinträchtigen.

Concurrent Queues: trügerischer Komfort

Seit Java 5 sind Concurrent Queues ein beliebtes Mittel zur einfachen und komfortablen Kommunikation zwischen zwei oder mehreren Threads, vor allem im Vergleich zu systemnäheren Mechanismen wie beispielsweise Locks.

ContentionAls C...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang