Высокочастотная торговля в JVM с помощью Scala / Akka - PullRequest
21 голосов
/ 31 марта 2012

Давайте представим гипотетическую HFT-систему в Java, требующую (очень) малой задержки, с множеством короткоживущих небольших объектов, в некоторой степени из-за неизменности (Scala?), Тысяч соединений в секунду и непристойного количества сообщенийвокруг в управляемой событиями архитектуре (akka и amqp?).

Для экспертов, что было бы (гипотетически) лучшим выбором для JVM 7?Какой тип кода сделает его счастливым?Будут ли Scala и Akka готовы к таким системам?

Примечание: Были некоторые похожие вопросы, такие как one , но я еще не нашелодин, охватывающий Scala (который имеет свой уникальный след в JVM).

Ответы [ 3 ]

35 голосов
/ 04 апреля 2012

В Java можно добиться очень хорошей производительности. Однако вопрос должен быть более конкретным, чтобы дать заслуживающий доверия ответ. Ваши основные источники задержек будут получены из неисчерпывающего списка:

  1. Сколько мусора вы создаете и работу GC по сбору и продвигать это. Неизменные конструкции в моем опыте не вписываются в с низкой задержкой. Настройка GC должна быть в центре внимания.

  2. Прогрейте JVM, чтобы классы были загружены и JIT успел делать свою работу.

  3. Разработайте ваши алгоритмы, чтобы они были O (1) или, по крайней мере, O (log2 n), и имеют тесты производительности, которые утверждают это.

  4. Ваш дизайн должен быть без блокировки и следовать " Single Writer Принцип ».

  5. Необходимо приложить значительные усилия для понимания целого стека и показывая механическое сочувствие в его использовании.

  6. Разработайте свои алгоритмы и структуры данных, чтобы они были удобны для кэширования. Кэши пропускают в эти дни самые большие затраты. Это тесно связан со схожест и значительное загрязнение кеша. Это будет включать симпатию к ОС и даже некоторый код JNI в некоторых случаях.

  7. Убедитесь, что у вас достаточно ядер, чтобы любой поток, который должен run имеет доступное ядро ​​без ожидания.

Я недавно написал в блоге о тематическом исследовании такого упражнения.

26 голосов
/ 01 апреля 2012

На моем ноутбуке средняя задержка пинг-сообщений между участниками Akka 2.3.7 составляет ~ 300 нс , и это намного меньше, чем ожидаемая задержка из-за пауз GC на JVM.

Код (включая опции JVM) и результаты тестов для Akka и других участников на Intel Core i7-2640M здесь .

P.S. Вы можете найти множество принципов и советов по вычислениям с малой задержкой на сайте Дмитрия Вьюкова и в блоге Мартина Томпсона .

11 голосов
/ 03 июля 2012

Вы можете обнаружить, что использование кольцевого буфера для передачи сообщений превзойдет то, что можно сделать с помощью Akka.Основная реализация кольцевого буфера, которую люди используют в JVM для финансовых приложений, - это система Disruptor, которая тщательно настроена на эффективность (мощность двух размеров), для JVM (без GC, без блокировок) и для современных процессоров (без ложного разделениястроки кэша).

Вот вступительная презентация с точки зрения Scala http://scala -phase.org /alks / jamie-allen-sdisruptor / index.html # 1 и тамссылки на последнем слайде на оригинальный материал LMAX.

...