Есть ли еще преимущества использования JRuby по сравнению с последней версией MRI с Puma?

Я рассматриваю возможность обновления нашего интерпретатора ruby ​​до JRuby, это было довольно головной болью, потому что нам пришлось удалить любой специфичный для 2.x синтаксис из нашего приложения и прибегнуть к совместимости с ruby ​​​​1.9.3. Что не является концом света.

Когда пришло время запустить приложение, я обнаружил, что мы не можем использовать Puma в кластерном режиме. Вопрос в том, учитывая все исправления и изменения в МРТ за последние несколько лет, остаются ли в силе преимущества наличия «настоящих нитей»?

обновить

Чтобы сделать это более объективным, задайте вопрос: «Отменяет ли последняя версия MRI необходимость принятия JRuby для достижения тех же преимуществ, что и нативные потоки?»


ruby puma mri jruby
person JP Silvashy    schedule 23.09.2014    source источник
comment
эй ... интересный вопрос, но он, скорее всего, попадет под флаг, основанный в первую очередь на мнении ... просто говорю   -  person Taryn East    schedule 24.09.2014
comment
Я не думаю, что это база мнений. Нам не хватает дополнительных доказательств, особенно экспериментальных.   -  person Ely    schedule 14.05.2015

Ответы (3)


arrow_upward
9
arrow_downward

Отменяет ли последняя версия MRI необходимость внедрения JRuby для достижения тех же преимуществ, что и нативные потоки?

Ответ - нет. Это не отменяет необходимости, и это зависит от вашего приложения, как указано в других ответах.

Кроме того, JRuby не позволяет вам работать в кластерном режиме, но это не проблема в отношении вашего вопроса, потому что он многопоточный и параллельный. Просто запустите в одиночном режиме столько потоков, сколько вам нужно. Он должен быть в полном порядке, если не даже более легким.

Позвольте мне дать вам несколько ссылок, которые дают больше информации и позволяют копать дальше.

В этом ответе обсуждаются эксперименты с MRI и JRuby, тестирующие одновременные запросы с использованием Puma (до 40 потоков). Это довольно всеобъемлющий.

Эксперименты доступны на GitHub, MRI и JRuby.

Предостережение заключается в том, что он проверяет только одновременные запросы, но не имеет состояния гонки в контроллере. Тем не менее, я думаю, вы могли бы реализовать тест из этой статьи Удаление config.threadsafe ! без особых усилий.

Разница между JRuby и MRI заключается в том, что JRuby может выполнять код параллельно. MRI ограничен GIL, и одновременно может выполняться только один поток. Дополнительную информацию о GIL можно прочитать в этой статье Никто не понимает ГИЛ.

Результаты весьма удивительны. МРТ быстрее, чем JRuby. Не стесняйтесь улучшать и добавлять условия гонки.

Обратите внимание, что оба являются многопоточными и не потокобезопасными. Разница в том, что MRI не может выполнять код параллельно, а JRuby может.

У вас может возникнуть соблазн сказать, почему я отвечаю «Нет», если эксперимент показывает, что МРТ работает быстрее.

Я думаю, нам нужно больше экспериментов и, в частности, реальных приложений.

Если вы считаете, что JRuby должен быть быстрее, потому что он может выполнять код параллельно, то причины могут быть следующими:

  • Эксперименты должны выполняться в высокопараллельной среде, чтобы можно было использовать потенциал JRuby.
  • Это может быть сам веб-сервер. Возможно, Puma не использует весь потенциал JRuby. У MRI есть GIL, так почему же он быстрее, чем JRuby, обрабатывает запросы?
  • Могут иметь значение и другие факторы, которые являются более глубокими, но мы еще не обнаружили...
person Ely    schedule 14.05.2015
comment
Я еще не запускал ваши тесты, но вы можете выполнить предварительный прогрев; JRuby становится существенно быстрее, как только появляется возможность включить JIT. - person Chris Heald; 10.07.2015
comment
@ChrisHeald Можете ли вы рассказать мне об этом подробнее, или у вас есть какие-нибудь ссылки, чтобы познакомить меня с этим JIT, который может помочь. Звучит интересно. - person Ely; 10.07.2015
comment
@Elyasin Просто сделайте более 100 запросов к приложению, прежде чем начинать измерения. По умолчанию JIT срабатывает после 50 вызовов метода. Первые два графика здесь иллюстрируют разрыв; Теплая виртуальная машина JRuby превосходит теплую виртуальную машину MRI, хотя холодная виртуальная машина MRI превосходит холодную виртуальную машину JRuby. Однако, поскольку приложения Rails, как правило, работают долго, обычно целесообразно смоделировать, как ваше приложение будет работать в течение длительного периода, выполнив предварительный прогрев перед тестированием. - person Chris Heald; 10.07.2015

arrow_upward
4
arrow_downward

На самом деле зависит от вашего сценария с веб-сервером (который вы должны иметь самое лучшее понимание) ... если вы чувствуете, что ваше производство просто хорошо работает под МРТ, тогда у вас, вероятно, не так много параллелизма вокруг. README от puma в значительной степени объясняет, что вы получаете при МРТ по сравнению с Rubinius/ JRuby:

В MRI существует глобальная блокировка интерпретатора (GIL), которая гарантирует, что одновременно может выполняться только один поток. Но если вы выполняете много блокирующих операций ввода-вывода (например, HTTP-вызовы к внешним API, таким как Twitter), Puma по-прежнему улучшает пропускную способность MRI, позволяя выполнять блокировку операций ввода-вывода одновременно (серверы на основе EventMachine, такие как Thin, отключают эту возможность, требуя использовать специальные библиотеки). Ваш пробег может отличаться. Чтобы добиться максимальной пропускной способности, настоятельно рекомендуется использовать реализацию Ruby с реальными потоками, например Rubinius или JRuby.

... так что одним предложением: ** под МРТ можно иметь несколько потоков, но параллелизма у вас нет **

person kares    schedule 29.09.2014
comment
Я не хотел неожиданно помещать это в редактирование и не хотел создавать новый ответ. Не могли бы вы добавить ссылку на мой ответ? Это связано с этим вопросом. В эксперименте (о параллелизме) MRI побеждает JRuby с использованием Puma. Ссылка: stackoverflow.com/a/30097643/1566187 - person Ely; 13.05.2015
comment
спасибо, но желательно (как в настоящее время) нет... это примечания, такие как те, что у людей создается впечатление, что JRuby бесполезен - пример кажется очень далеким от реальных чисел (не говоря уже о запуске JRuby в режиме разработки, в то время как МРТ идет в производство), и я не вижу, как это сделает этот ответ более ясным (на самом деле вносит больше путаницы). тестовый пример с использованием sleep() также неудачен. - person kares; 13.05.2015
comment
Хорошо, это честный ответ. Спасибо. - person Ely; 13.05.2015

arrow_upward
3
arrow_downward

ИМХО Это зависит от того, что делает ваше приложение.

Я протестировал MRI/YARV и JRuby в своем приложении Rails. Поскольку большая часть того, что делает приложение, — это маршрутизация HTTP-запросов, выборка из БД, применение простой бизнес-логики и запись в БД, параллелизм не является большой проблемой. Puma на MRI поддерживает многопоточность для блокировки операций ввода-вывода (БД, API). Задачи, выходящие за рамки этой области (обработка изображений, обработка данных отчетов, вызовы внешних API и т. д.), вероятно, в любом случае должны обрабатываться фоновыми заданиями (я рекомендую https://github.com/brandonhilkert/sucker_punch).

В зависимости от потребностей вашего развертывания потребление памяти может быть более серьезной проблемой, а JRuby очень нуждается в памяти. Почти в 2 раза больше памяти в моем случае.

Если вы развертываете свое приложение на Heroku, вы можете обнаружить, что получаете больше отдачи от затраченных средств, имея возможность одновременно запускать 2 экземпляра на 1 динамометрическом стенде.

person Jim    schedule 17.12.2014