Эффективность Erlang (или эликсира) (запросы в секунду) медленна против jruby?

Будучи рубистом, я решил взять erlang для высокой производительности, надежного бэкэнд. Настройка довольно проста: получить почтовый запрос, написать материал для повтора, вернуть статистику. Все json. поэтому я так сильно забочусь о запросах в секунду.

Инструменты выбора: webmachine, jiffy для кодирования/декодирования json, poolboy для пула соединений и eredis для обмена сообщениями.

Используемая машина: macbook pro, i5 2.4Ghz, память 8 ГБ.

Мой erlang получил около 5000 запросов в секунду, а jruby/torqbox получил около 12 0000. (посмотрите здесь полную установку теста производительности рубинов)

Я понимаю, что я мог бы использовать ets в erlang, чтобы сэкономить время, и оставьте redis для "фоновой обработки", который будет написан после ответа, но это будет иметь мало влияния. даже простой тест "hello world" erlang legs позади.

Любые предложения? Я делаю это неправильно?

Ответ 1

Webmachine - я не знаю. Это очень тяжелый вес для моего вкуса, и я не использую его.
jiffy - Хороший выбор. Довольно быстро, и я использую его много.
poolboy - я не слышал об этом, и я уже несколько лет обхожусь вокруг Эрланг. Я определенно использовал бы cowboy для чего-то, что я ожидал бы высокой производительности или yaws для некоторых более твердый камень, но все еще хорошо. Для вашего бенчмарка правильный выбор ковбоя, он является лучшим по производительности.
eredis - я не знаю, насколько зрелым и насколько он эффективен. ets более подходит для бенчмарка. Для вашего теста macbook это не имеет значения, но для большого сервера (десятки процессоров) я бы проверял, не является ли ti узким местом и таблицей разделов.
Самое главное проверить параметры виртуальной машины. По крайней мере, вы должны иметь +K true +A 100 для такого типа нагрузки.

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

И в основном это важно, это можно считать не только микро-критерием для мира Эрланг, но и может быть наном или атто. Реальная сила покажет, когда вы попытаетесь сделать что-то еще сложнее и сложнее. Что-то, где параллельный запрос должен влиять друг на друга очень сложным образом, и вам нужно иметь дело с возможной согласованностью и реализовать его гораздо более масштабируемым и использовать асинхронную межпроцессную связь.

Ответ 2

Мои 2 цента. У вас неправильный конец палки. Вы тестируете проблему, с которой JVM оптимизирован для какой-то машины, для которой оптимизирована JVM.

Вы действительно не увидите преимуществ Erlang/OTP по количеству ядер, доступных на mac book pro. Это просто мое предварительное предположение, но я был бы удивлен, увидев, как Эрланг победил JVM на чем-то меньшем, чем 8-ядерный сервер. Огромное количество человек/часов было поставлено на создание JVM как можно быстрее на текущем оборудовании.

Написание безопасного кода ввода-вывода Thread довольно прост, реальные проблемы возникают, когда вы имеете дело с доступом к памяти от десятков до сотен потоков.

Запись в Erlang/Elixir нацелена на текущий сервер высокого уровня из 16 или 32 ядер с возможностью масштабирования намного выше в ближайшем будущем.

Ответ 3

FYI: "+ A 100" не помогло бы в сети, это только для файла IO. Если вы действительно хотите, чтобы быстрый веб-сервер взглянул на github.com/knutin/elli, он даст вам 80 кпс на аппаратном обеспечении, где ковбой даст вам 30 кр/с. С другой стороны, elli - это то, что многие люди обвиняют в том, что не соблюдают принципы OTP.

jiffy - отличный выбор, если вы можете разместить некоторый балансировщик нагрузки для дезинфекции запросов, потому что jiffy представит segfaults для вашего кода - посмотрите на список проблем.

В любом случае erlang не то, что вы можете выбрать, если все, что вам нужно, очень быстро GET → decode json → store → REPLY workload.