Trading ad alta frequenza in JVM con Scala/Akka

Question

Immaginiamo un ipotetico sistema HFT in Java, che richiede (molto) bassa latenza, con un sacco di piccoli oggetti di breve durata in qualche modo dovuti a immutabilità (Scala?), Migliaia di connessioni al secondo e un osceno numero di messaggi che passano in giro in un'architettura basata sugli eventi (akka e amqp?).

Per gli esperti là fuori, quale sarebbe (ipoteticamente) la migliore messa a punto per JVM 7? Quale tipo di codice lo renderebbe felice? Scala e Akka sarebbero pronti per questo tipo di sistemi?

Nota: Ci sono state alcune domande simili, come questo one, ma non ho ancora trovato uno che copre Scala (che ha la sua impronta idiosincratica nella JVM).

Answer 1

Sul mio portatile la latenza media dei messaggi ping tra gli attori di Akka 2.3.7 è ~300ns ed è molto inferiore alla latenza prevista a causa delle pause GC su JVM.

Codice (comprese le opzioni JVM) & risultati dei test per Akka e altri attori su Intel Core i7-2640M here.

P.S. È possibile trovare molti principi e suggerimenti per l'elaborazione a bassa latenza su Dmitry Vyukov site e su Martin Thompson blog.

Answer 2

È possibile ottenere prestazioni molto buone in Java. Tuttavia, la domanda deve essere più specifica per fornire una risposta credibile. I suoi principali fonti di latenza verranno da seguire elenco non esaustivo:

1. quanta immondizia si crea e il lavoro del GC di raccogliere e promuoverlo. I progetti immutabili nella mia esperienza non si adattano bene alla latenza . La messa a punto del GC deve essere un grande obiettivo.

2. Riscaldare la JVM in modo che le classi siano caricate e il JIT abbia avuto il tempo per svolgere il proprio lavoro.

3. Progettare gli algoritmi in modo che siano O (1) o almeno O (log2 n) e avere test di prestazioni che lo affermano.

4. Il design deve essere privo di blocco e seguire "Single Writer Principle".

5. È necessario un notevole sforzo per comprendere l'intero stack e mostrare la simpatia meccanica nel suo utilizzo.

6. Progettare gli algoritmi e le strutture dati in modo che siano compatibili con la cache. La mancanza di cache in questi giorni è il costo maggiore. Questo è strettamente correlato all'affinità dei processi che, se non impostato correttamente, può causare e un significativo inquinamento della cache. Ciò comporterà la comprensione per il sistema operativo e anche alcuni codici JNI in alcuni casi.

7. Verificare di disporre di nuclei sufficienti in modo che qualsiasi thread che deve eseguire abbia un nucleo disponibile senza dover attendere.

Recentemente ho bloggato su un case study di un tale esercizio.

Answer 3

È possibile che l'uso di un buffer circolare per il passaggio dei messaggi superi quello che può essere fatto con Akka. L'implementazione del buffer dell'anello principale che le persone utilizzano sulla JVM per le applicazioni finanziarie è quella chiamata Disruptor che è attentamente sintonizzata per efficienza (potenza di due dimensioni), per JVM (senza GC, senza blocchi) e per CPU moderne (nessuna condivisione falsa di linee della cache).

Ecco una presentazione di introduzione dal punto di vista Scala http://scala-phase.org/talks/jamie-allen-sdisruptor/index.html#1 e ci sono collegamenti nell'ultima diapositiva al materiale originale di LMAX.