Trading de alta frecuencia en la JVM con Scala/Akka

Question

Imaginemos un sistema HFT hipotético en Java, que requiere (muy) baja latencia, con muchos objetos pequeños de corta duración debido a la inmutabilidad (Scala?), Miles de conexiones por segundo, y una cantidad obscena de mensajes que circulan en una arquitectura impulsada por eventos (akka y amqp?).

Para los expertos, ¿cuál sería (hipotéticamente) el mejor ajuste para JVM 7? ¿Qué tipo de código lo haría feliz? ¿Estarían listos Scala y Akka para este tipo de sistemas?

Nota: Ha habido algunas preguntas similares, como este one, pero todavía tengo que encontrar uno que cubre Scala (que tiene su propia huella idiosincrásico en la JVM).

Answer 1

En mi computadora portátil, la latencia promedio de los mensajes de ping entre los actores de Akka 2.3.7 es ~300ns y es mucho menor que la latencia esperada debido a las pausas de GC en las JVM.

Código

(incluidas las opciones de JVM) & resultados de pruebas para Akka y otros actores en Intel Core i7-2640M here.

P.S. Puede encontrar muchos principios y consejos para la computación de baja latencia en Dmitry Vyukov's site y en Martin Thompson's blog.

Answer 2

Es posible lograr un muy buen rendimiento en Java. Sin embargo, la pregunta debe ser más específica para proporcionar una respuesta creíble. Sus principales fuentes de latencia vendrán de seguir lista no exhaustiva:

1. ¿Cuánta basura se crea y el trabajo de la GC para recopilar y promoverla. Los diseños inmutables en mi experiencia no encajan bien con de baja latencia. La sintonización de GC necesita ser un gran foco.

2. Caliente la JVM para que las clases estén cargadas y el JIT haya tenido tiempo para hacer su trabajo.

3. Diseñe sus algoritmos para que sean O (1) o al menos O (log2 n), y tengan pruebas de rendimiento que lo afirman.

4. Su diseño debe ser seguro y seguir el "Single Writer Principle".

5. Es necesario realizar un gran esfuerzo para comprender la totalidad de la pila y mostrar simpatía mecánica por su uso.

6. Diseñe sus algoritmos y estructuras de datos para que sean compatibles con la memoria caché. Los errores de caché en estos días son el mayor costo. Está estrechamente relacionado con afinidad con el proceso que, si no está configurado correctamente, puede dar como resultado y una importante contaminación del caché. Esto implicará simpatía por el sistema operativo e incluso algún código JNI en algunos casos.

7. Asegúrese de tener suficientes núcleos para que cualquier subproceso que necesite ejecutar tenga un núcleo disponible sin tener que esperar.

Hace poco publiqué sobre un case study de tal ejercicio.

Answer 3

Es posible que el uso de un buffer en anillo para el envío de mensajes supere lo que se puede hacer con Akka. La implementación principal del buffer circular que la gente usa en la JVM para aplicaciones financieras es una llamada Disruptor que está cuidadosamente ajustada para eficiencia (potencia de dos tamaños), para JVM (sin GC, sin bloqueos) y para CPU modernas (sin compartir falsamente líneas de caché).

Aquí hay una presentación introductoria desde el punto de vista de Scala http://scala-phase.org/talks/jamie-allen-sdisruptor/index.html#1 y hay enlaces en la última diapositiva a las cosas originales de LMAX.