Comments 24
А мы перешли на puma и забыли unicorn как страшный сон.
вы используете Пуму на MRI? Расскажите про преимущества по сравнению с unicorn, с какими трудностями столкнулись при переходе?
Когда в последний раз тестировал: при 8 потоках пума использовала в 10 раз меньше памяти чем юникорн (при тех же 8 потоках) и обрабатывала в полтора раза больше запросов.
Тестировал на амазоновском сервере с помощью ab, уже не помню конфигурацию, было что-то около 4-х ядер и 4гб памяти.
Трудностей вообще никаких, конфигурируется она сильно проще чем юникорн.
Тестировал на амазоновском сервере с помощью ab, уже не помню конфигурацию, было что-то около 4-х ядер и 4гб памяти.
Трудностей вообще никаких, конфигурируется она сильно проще чем юникорн.
Я не в курсе, но может вы знаете ответ. Вот у юникорна при деплое воркеры заменяются на новые постепенно, в итоге, сайт непрерывно продолжает работать. А у puma с этим как? Там есть такое, или ставится заглушка, что сайт обновляется?
Тут кстати логичный вопрос. У уникорна нет потоков, только воркеры, в то время как у пумы — потоки + кластер режим, что означает тоже самое, что и у юникорна. Тоесть вы сравнивали производительность 8 workers unicorns vs 8 puma cluster mode без тредов внутри каждого? Поскольку только так тестирование будет приближено к реальности тестирования самого веб сервера. Ведь puma выиграет, поскольку из коробки один демон создает 16 тредов, что уже дает фору (но и создает проблемы в MRI).
UFO just landed and posted this here
zero downtime restart?
Ну и в nginx'е нужно писать всего одну строчку на все воркеры юникорна, а не по одной на каждой :)
Ну и в nginx'е нужно писать всего одну строчку на все воркеры юникорна, а не по одной на каждой :)
Nginx:
Puma:
Zero downtime:
upstream prodpuma {
server unix:/.../shared/tmp/sockets/puma.sock fail_timeout=0;
}
Puma:
bind 'unix:///.../shared/tmp/sockets/puma.sock' state_path '/.../shared/tmp/sockets/puma.state'
Zero downtime:
desc 'Restart puma (phased restart)'
task :phased_restart, :roles => lambda { puma_role }, :on_no_matching_servers => :continue do
run "cd #{current_path} && #{pumactl_cmd} -S #{state_path} phased-restart"
end
Да, кстати, если уж и сравнивать, то unicorn и rainbows!, то последний основан на первом. Основное отличие — разные задачи использования. Задача unicorn — обслуживание быстрых запросов, в то время как для rainbows! — долго «живучих» запросов. Поэтому первый хорош для простых сайтов с запрос-ответ (тоесть почти для всех веб сайтов), а второй для обслуживание websocket или commet соединений.
Использую связку 1 Nginx + 20 Thin. Версия руби 1.8.7 и вполне доволен скорость работы. Памяти используется очень мало.
Unicorn устанавливал один раз. После его запуска был поражен сколько памяти он «съел» по сравнению с Thin. Автору может быть присмотреться к другим веб-серверам? Чем уж так хорош Unicorn? Или просто лень переучиваться?
Unicorn устанавливал один раз. После его запуска был поражен сколько памяти он «съел» по сравнению с Thin. Автору может быть присмотреться к другим веб-серверам? Чем уж так хорош Unicorn? Или просто лень переучиваться?
А почему passenger не обсуждается в комментариях?
Т.к. созданные (форкнутые) процессы являются копиями друг друга, это значит, что rails-приложение должно быть потокобезопасным.Неправда.
Странно, но мы всегда находили и исправляли утечку памяти. Вариант unicorn-worker-killer уже если вообще команда не может с этим справится (хотя мы monit для этого использовали, что бы следить за памятью — он сразу и писал письмо, что воркер пришлось перегрузить). Но это точно не решает проблему с утечками.
Sign up to leave a comment.
Как оптимизировать процессы Unicorn в Ruby on Rails приложении