Thin, Unicorn, Rainbows, Passenger, Puma, ?

drakmail рекомендует passenger

Я бы заюзал Puma.

Юзаю Unicorn на 300-400 Rails-приложениях … В следствии этого, могу сказать, что он работает хорошо. :)

Профит от Puma можно получить юзая не MRI.

Юзаю Unicorn на 300-400 Rails-приложениях … В следствии этого, могу сказать, что он работает хорошо. :)

то есть вы просто его всегда использовали и он просто всегда работал? или это сознательный выбор?

Когда пришел туда, то «местная религия» была юзать Unicorn. Как я понял, до этого они юзали Passenger, почему мигрировали уже не помню, но постараюсь сегодня уточнить. ;)

Пробовал в своё время всё из этого, unicorn показался немного медленным, puma - на MRI у меня вообще доходило до странных падений или зависаний, thin - понравился больше всего, прост и быстр. Но из-за удобства деплоя потихоньку меняю этот зоопарк на passenger - первые сайты уже перенёс, всё радует.

В чем удобство деплоя пассажира перед thin?

В чем удобство деплоя пассажира перед thin?

Тоже интересно узнать.

Тем, что просто кинул в папку, указал nginx-passenger, что за папка - и всё, оно заработало. Без старта лишних серверов, прописывания в nginx проксей и прочего.

Тем что оно интегрируется в nginx и управляется из единого конфига, а не стопиццот конфигов отдельно для статики, отдельно для воркеров и отдельно для прокси. + умеет поднимать приложение по запросу и выключать при неактивности.

Тем что оно интегрируется в nginx и управляется из единого конфига, а не стопиццот конфигов отдельно для статики, отдельно для воркеров и отдельно для прокси

разве это unix-way? ;)

Все, что мне встречалось на рельсах, было запущено через nginx + unicorn. Всегда считал что это вариант де-факто, хотя возможно эта связка подустарела, не знаю т.к не рубист.

то есть вы просто его всегда использовали и он просто всегда работал? или это сознательный выбор?

Узнал из-за чего отказались от Passenger'a - все просто!
Дело во внутренней инфраструктуре хостинга, и что unicorn показался «как-то логичнее и проще» админу на тот момент. :D

Долго использовал Unicorn + Nginx, работал хорошо.

Сейчас использую Passenger + Nginx, работает хорошо. Конфиг разве что покороче для него.

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

У меня обратная ситуация - в какой-то момент passenger показался (и оказался на деле) удобнее и проще :)

Когда говорят, что Unicorn только для fast clients - подразумевается, что перед ним необходим reverse proxy сервер (nginx). В Unicorn-е запросы обрабатывают несколько процессов worker-ов (которых заведомо меньше чем клиентов), и каждый из них блокируется на время обработки запроса. В случае медленного клиента worker будет заблокирован пока не передаст ответ клиенту, вместо того, чтобы обрабатывать следующий запрос. В случае использования прокси worker быстро ему отвечает и освобождается. Прокси же в силу своей асинхронности способен эффективно передать ответ медленному клиенту.

Чем это лучше passenger?

Для начала проблема: при обработке запросов происходят блокировки на время работы сети, иначе говоря: «запросы обрабатываются медленно».

Решение:
а) использовать неблокирующую архитектуру
б) использовать несколько потоков/экземпляров приложений

Второй вариант порождает еще проблемы:
а)В mri нет настоящих потоков.
б)При большом количестве конкурирующих запросов, большее количество приложений не сильно помогает, а вот ресурсы пожирает вполне стабильно.

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

thin использует eventmachine, что, вероятно, уменьшает количество блокировок при обработке запросов. Кроме того существует возможность занять весь поток, используя https://github.com/mperham/rack-fiber_pool/, это потребует определенных библиотек для работы с БД, http запросов и пр.

unicorn, использует fork и unix socket http://tomayko.com/writings/unicorn-is-unix https://blog.engineyard.com/2010/everything-you-need-to-know-about-unicorn считается плохо подходящим для «медленных» клиентов (очевидно он просто их не обрабатывает, разрывая соединение, убивая воркер и т.п.).

rainbow работает так же как и unicorn, но при этом умеет еще и другие «модели обеспечения конкуренции», в т.ч eventmachine.

puma использует ruby-threads вместо fork, благо в паре реализация они вполне реальные. С epool puma так же работает.

passanger, похоже, часть работы оставляет на apache/nginx, тоже умеет работать с epool.

Меня немного напрягает, что если принцип работы thin и unicorn понятен, то с остальными все не так очевидно. Но, думаю, каждый из них по-своему хорош. Хотя, лично я, в первую очередь за non-blocking, т.о. мне подходят все кроме unicorn. С другой стороны, почему бы не использовать unicorn там где все быстро и что-нибудь другое, где все медленно. Короче, серебренной пули нет.

геморойность деплоя

написал такой файлег

description "description"
 
env USER=special-k
env RBENV_VERSION=rbx-2.1.1
env RBENV_BIN_PATH=/home/special-k/.rbenv/bin
env PATH=/home/special-k/.rbenv/shims:/home/special-k/.rbenv/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

env PORT=9292
env APP_DIR=/home/appdir
limit rss 314572800 314572800

exec start-stop-daemon --start -c app --chuid ${USER} -d $APP_DIR \
     -x ${RBENV_BIN_PATH}/rbenv -- exec puma config.ru -p ${PORT} -e production

пс
это wet upstartа напрягает конечно..

И такой для каждого сайта надо. А потом еще и в nginx проксирование прописывать. Тоже для каждого сайта. Когда можно с passenger тупо в nginx добавить 1 строчку и оно само подхватится.

А там ему не свой какой-то nginx нужен, часом..?

И такой для каждого сайта надо.

Хз.. 4 thin (например) запускать в одном ли файле надо..

И такой для каждого сайта надо.

Естественно. А по хорошему ещё каждый сайт надо дебианизировать для удобства деплоя.

Обычный nginx с патчами, в дебиане ставится буквально одной командой (если интересно, как - http://drakmail.ru/2014/01/05/migrate-from-nginx-to-nginx-passenger.html)

И зачем мне nginx + 100500 thin'ов, если можно обойтись лишь nginx? А для удобства деплоя, имхо, идеален ansible + mina, так как нету зависимости от ОС.

Thin я давно не юзал, Rainbows! не юзал вообще, так что расскажу про остальные:

1. Все три на данный момент примерно одинаково стабильны, только тут надо учитывать, что Пума хорошо себя ведёт только с рубями, где запилена Ъ-многопоточность (я юзаю Рубиниус).
2. Раньше Пассажир конкретно заруливал в этом аспекте (особенно в связке с REE), а Единорог жрал нереально много. С переходом на руби 2.0 разница заметно нивелировалась. Пума где-то между ними.
3. Тут Пассажир вне конкуренции.
4. Здесь Пума сливает, если используется Рубиниус, потому что он заметно дольше стартует. Пассажир и Единорог, думаю, примерно одинаково, особенно, если окружение долго стартует, то время старта самого сервера будет неразличимо.
5. Самый сложный вопрос :) Мы для новый приложений всё чаще выбираем Пуму, потому что Рубиниус почти готов, а потоки рулят.

в дебиане ставится буквально одной командой

Что-то какая-то длинная команда, состоящая из множества частей -_-

Это многосторонний вопрос, тут не может быть одного мнения. В определенном роде действительно проще собрать пакет, который пульнет по файлегу в /etc/init и /etc/nginx/sites-available, и передать его системе конфигурации основанной на пакетах ОС (которую еще надо запустить и настроить конечно же), задействуя все имеющиеся инструменты для контроля и мониторинга. Иногда проще деплоить из системы контроля версий, это может быть на определенной стадии (разработки и тестирования) жизни приложения. Или еще, я хочу использовать конкретный сервер, goliath какой-нибудь, и не больно-то прокатит твой passenger, выйдет, что разные приложения требуют разного подхода к деплоингу и обслуживанию. Но стандартизироваться тоже надо в меру и не без причины.