Улучшение пропускной способности Akka

Question

Мы думаем об использовании Akka для связи с клиентским сервером и попытке сопоставить передачу данных. В настоящее время мы пытаемся отправить миллион сообщений, где каждое сообщение является классом case с 8 строковыми полями.

На данный момент мы изо всех сил пытаемся получить приемлемую производительность. Мы видим около 600KB/s скорость передачи и простаивающие процессоры на клиенте и сервере, поэтому что-то идет не так. Может быть, это наша сетевая конфигурация.

Это наш Akka конфигурации

Server { 
    akka { 
    extensions = ["akka.contrib.pattern.ClusterReceptionistExtension"] 
    loggers = ["akka.event.slf4j.Slf4jLogger"] 
    loglevel = "DEBUG" 
    logging-filter = "akka.event.slf4j.Slf4jLoggingFilter" 
    log-dead-letters = 10 
    log-dead-letters-during-shutdown = on 
    actor { 
     provider = "akka.cluster.ClusterActorRefProvider" 
    } 
    remote { 
     enabled-transports = ["akka.remote.netty.tcp"] 
     netty.tcp { 
     hostname = "instance.myserver.com" 
     port = 2553 
     maximum-frame-size = 1000 MiB 
     send-buffer-size = 2000 MiB 
     receive-buffer-size = 2000 MiB 
     } 
    } 
    cluster { 
     seed-nodes = ["akka.tcp://server@instance.myserver.com:2553"] 

     roles = [master] 
    } 
    contrib.cluster.receptionist { 
     name = receptionist 
     role = "master" 
     number-of-contacts = 3 
     response-tunnel-receive-timeout = 300s 
    } 
    } 

} 

Client { 
    akka { 
    loggers = ["akka.event.slf4j.Slf4jLogger"] 
    loglevel = "DEBUG" 
    logging-filter = "akka.event.slf4j.Slf4jLoggingFilter" 
    actor { 
     provider = "akka.remote.RemoteActorRefProvider" 
    } 
    remote { 
     enabled-transports = ["akka.remote.netty.tcp"] 
     netty.tcp { 
     hostname = "127.0.0.1" 
     port = 0 
     maximum-frame-size = 1000 MiB 
     send-buffer-size = 2000 MiB 
     receive-buffer-size = 2000 MiB 
     } 
    } 
    cluster-client { 
     initial-contacts = ["akka.tcp://server@instance.myserver.com:2553/user/receptionist"] 
     establishing-get-contacts-interval = "10s" 
     refresh-contacts-interval = "10s" 
    } 
    } 

} 

UPDATE:

В конце концов, несмотря на дискуссии о сериализации (смотри ниже), мы просто конвертируются наши полезные нагрузки, чтобы использовать массивы байтов, что способ сериализации не будет влияют на тесты. Мы обнаружили, что на ядре i7 с 24-гигабайтным барабаном с использованием jeroMQ (т. Е. ZeroMQ, повторно реализованный в java, так что все еще не самый быстрый) мы видели последовательно около 200k msgs/sec или около 20 MB/sec, а на raw akka (то есть без плагина zeroMQ) мы видели около 10 тыс. msgs/sec или чуть меньше 1 МБ/с. Попытка на akka + zeroMQ сделала работу хуже.

Answer 1

Чтобы упростить работу с удалением, akka использует сериализацию Java для сериализации сообщений, это не то, что вы обычно используете в производстве, потому что это не очень быстро и не справляется с управлением версиями сообщений.

Что вы должны сделать, это использовать kryo или protobuf для сериализации, и вы сможете получить гораздо лучшие числа.

Вы можете прочитать о том, как здесь, есть также несколько ссылок на доступные сериализаторы в нижней части страницы: http://doc.akka.io/docs/akka/current/scala/serialization.html

Answer 2

Ok вот что мы обнаружили:

Используя нашу модель клиент-сервер, мы смогли получить около < 3000 Сообщ/сек, не делая ничего, что не было действительно приемлемо для нас, но мы действительно были смущены тем, что было потому что мы не смогли максимизировать процессор.

Поэтому мы вернулись к исходному Akka кода и нашел образец бенчмаркинга там:

sample.remote.benchmark.Receiver

sample.remote.benchmark.Sender

Эти два класса, которые используют AKKA пульт для пинг-понг себя кучу сообщений от двух jvms на той же машине. Используя этот бенчмарк, мы смогли получить около 10 ~ 15k msg/sec на Corei7 с 24g, используя около 50% процессора. Мы обнаружили, что корректировка диспетчеров и потоков, распределенных для нетти, делала разницу, но только незначительно. Использование запросов вместо подсказок делало это немного медленнее, но не сильно. Использование балансировочного пула многих актеров для отправки и получения сделало его значительно медленнее.

Для сравнения мы выполнили аналогичный тест с использованием jeromq, и нам удалось получить около 100 тыс. Msg/sec с использованием 100% -ного CPU (той же полезной нагрузки, той же машины).

Мы также взломали отправителя и приемников, чтобы использовать расширение Akka zeromq для передачи сообщений непосредственно с одного jvm на другой, минуя akka remote вместе. В этом тесте мы обнаружили, что мы могли бы быстро отправить и принять, чтобы начать с, около 100 тыс. Msg/sec, но эта производительность быстро ухудшилась. При дальнейшем обследовании нити zeromq и аккордирование акка не играют вместе. Вероятно, мы могли бы настроить производительность, используя умнее, как zeromq и akka взаимодействовали друг с другом, но в этот момент мы решили, что было бы лучше пойти с необработанным zeromq.

Вывод: не используйте akka, если вы заботитесь о быстрой сериализации большого количества данных по проводу.