В чем разница между Passenger, Puma, Webrick и др

#ruby_on_rails #nginx

Добрый день, стоит задача в девелопмент-среде подключить к Rails-проекту nginx. В
статьях в сети заметил, что используются различные связки nginx с другими серверами
(встренными?). Я так понял, что nginx работает только в связке (с\на\под другим сервером
приложений)? Не пойму в чем принципиальная разница между Puma, Webrick, Phusion Passenger,
и как они взаимодействуют с nginx? Какие еще связки для рельсы с nginx существуют?
Какая предпочтительнее?

з.ы. рельсу только учу
з.ы.ы. спасибо.
    

Ответы

Ответ 1

Всё просто. Но много.

Вебсервер разделяется на:


сервер приложения


занимается непосредственно кодом приложения
в случае Ruby on Rails любой Rack-совместимый (WEBrick, Puma, и т. п.): он принимает
в качестве приложения какой-нибудь объект на Ruby с методом call (так называемый Rack
handler), в аргументах получает среду запроса, а вернуть должен массив вида [статус_код,
заголовки, массив_строк_кусков_тела_ответа]

обратный прокси (в вашем случае nginx, видел ещё Varnish, HAProxy, Cherokee), который
при различных обстоятельствах может быть также:


балансировщиком нагрузки — чтобы можно было поднять несколько серверов приложения
(возможно даже на разных машинах)
сервером раздачи статики — поскольку такой сервер обычно гораздо эффективнее для
этой задачи, чем любой Rack-совместимый сервер. Причём nginx может раздавать статику
как сам (если обнаруживает по пути запроса файл в файловой системе), так и по указанию
в ответе с сервера приложения (заголовком X-Accel-Redirect, при котором статика отправляется
вместо ответа).



Соответственно... о Rack-совместимых серверах.


Webrick — просто бесхитростный вебсервер на Ruby. Медленный, однопоточный, зато в
стандартной библиотеке и не требует установки каких бы там ни было гемов.
Unicorn — спроектирован для быстрой обработки запросов, однопоточный, но многопроцессный.
Был рекомендованным для Heroku сервером ранее, но... Уязвим для медленных клиентов:
если клиент медленно принимает ответ, Unicorn будет продолжать "кормить его с ложечки"
и не сможет обслуживать другие запросы. Посему для размещения в интернете обратный
прокси для него практически обязателен.
Puma — сравнительно новый (2011) вебсервер, умеющий и многопроцессность, и многопоточность
(для каждого входящего запроса создаётся новый поток), от медленных клиентов он не
страдает, поскольку может обслуживать нескольких одновременно. Heroku рекомендует на
своих серверах пользоваться именно им. Может работать в несколько процессов на единственном
Unix-сокете.
Thin — в целом, сопоставим по функциональности с Puma, использует событийный IO на
основе EventMachine. В многопроцессном режиме создаёт несколько сокетов, раскидывать
запросы между ними должен отдельный балансировщик, например nginx.
Passenger — тоже богатый на разные фичи вебсервер, сопоставим с Puma, местами даже
превосходит его, но самые вкусные фишки (перезапуск без простоя, многопоточность) есть
только в коммерческой версии. Ресурсопотребление довольно эффективное, а кроме как
на Ruby, можно запускать приложения ещё и на Node.js. Есть платная поддержка (для тех,
кому она нужна).


Выбор непростой, каждый случай стоит рассматривать отдельно. Puma сгодится практически
всегда, но в ряде случае можно увеличить эффективность, перейдя на что-нибудь другое.

С nginx они все взаимодействуют одинаково, как с обратным прокси: сидят где-нибудь
на недоступном из внешнего мира адресе (localhost, Unix domain socket или другой хост
во внутренней сети), запросы получают только от nginx, отвечают ему же.



См. также: Работа серверного приложения.