Comments 24
вы используете Пуму на MRI? Расскажите про преимущества по сравнению с unicorn, с какими трудностями столкнулись при переходе?
+1
Когда в последний раз тестировал: при 8 потоках пума использовала в 10 раз меньше памяти чем юникорн (при тех же 8 потоках) и обрабатывала в полтора раза больше запросов.
Тестировал на амазоновском сервере с помощью ab, уже не помню конфигурацию, было что-то около 4-х ядер и 4гб памяти.
Трудностей вообще никаких, конфигурируется она сильно проще чем юникорн.
Тестировал на амазоновском сервере с помощью ab, уже не помню конфигурацию, было что-то около 4-х ядер и 4гб памяти.
Трудностей вообще никаких, конфигурируется она сильно проще чем юникорн.
+2
Я не в курсе, но может вы знаете ответ. Вот у юникорна при деплое воркеры заменяются на новые постепенно, в итоге, сайт непрерывно продолжает работать. А у puma с этим как? Там есть такое, или ставится заглушка, что сайт обновляется?
+1
Тут кстати логичный вопрос. У уникорна нет потоков, только воркеры, в то время как у пумы — потоки + кластер режим, что означает тоже самое, что и у юникорна. Тоесть вы сравнивали производительность 8 workers unicorns vs 8 puma cluster mode без тредов внутри каждого? Поскольку только так тестирование будет приближено к реальности тестирования самого веб сервера. Ведь puma выиграет, поскольку из коробки один демон создает 16 тредов, что уже дает фору (но и создает проблемы в MRI).
0
UFO just landed and posted this here
zero downtime restart?
Ну и в nginx'е нужно писать всего одну строчку на все воркеры юникорна, а не по одной на каждой :)
Ну и в nginx'е нужно писать всего одну строчку на все воркеры юникорна, а не по одной на каждой :)
0
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
+1
Да, кстати, если уж и сравнивать, то unicorn и rainbows!, то последний основан на первом. Основное отличие — разные задачи использования. Задача unicorn — обслуживание быстрых запросов, в то время как для rainbows! — долго «живучих» запросов. Поэтому первый хорош для простых сайтов с запрос-ответ (тоесть почти для всех веб сайтов), а второй для обслуживание websocket или commet соединений.
0
Использую связку 1 Nginx + 20 Thin. Версия руби 1.8.7 и вполне доволен скорость работы. Памяти используется очень мало.
Unicorn устанавливал один раз. После его запуска был поражен сколько памяти он «съел» по сравнению с Thin. Автору может быть присмотреться к другим веб-серверам? Чем уж так хорош Unicorn? Или просто лень переучиваться?
Unicorn устанавливал один раз. После его запуска был поражен сколько памяти он «съел» по сравнению с Thin. Автору может быть присмотреться к другим веб-серверам? Чем уж так хорош Unicorn? Или просто лень переучиваться?
-1
Это ж как вы забили на технический долг, раз используете 1.8.7, на который уже даже security обновления не выходят :)
0
А почему passenger не обсуждается в комментариях?
+2
Т.к. созданные (форкнутые) процессы являются копиями друг друга, это значит, что rails-приложение должно быть потокобезопасным.Неправда.
0
Странно, но мы всегда находили и исправляли утечку памяти. Вариант unicorn-worker-killer уже если вообще команда не может с этим справится (хотя мы monit для этого использовали, что бы следить за памятью — он сразу и писал письмо, что воркер пришлось перегрузить). Но это точно не решает проблему с утечками.
0
Sign up to leave a comment.
Как оптимизировать процессы Unicorn в Ruby on Rails приложении