Какой из них лучше использовать вместе с последним приложением rails? Дворняга, Тонкий, ВЕБрик и Пассажир

Я играл и оценивал другие варианты для сервера WEBrick по умолчанию для рельсов, и Thin был самым безболезненным и чистым, который работал очень хорошо!

какой из этих Mongrel, Thin, WEBrick и Passenger вы бы порекомендовали и почему..? Существуют ли какие-либо преимущества масштабируемости (дружественные к кластерам или конфигурации, которые могут обрабатывать какой-либо масштаб), которые поставляются с любым из этих серверов ... или масштабируемость должна быть параметром при их оценке?


ruby-on-rails scalability passenger thin mongrel
person brucewayne    schedule 27.10.2012    source источник

Ответы (3)


arrow_upward
9
arrow_downward

Дипак уже ответил на половину вашего вопроса, но позвольте мне немного прояснить ситуацию. (Я один из авторов Phusion Passenger.)

  • WEBrick — игрушечный веб-сервер. Никто не использует его ни в чем, кроме разработки, потому что он плохо работает и, как говорят, приводит к утечке памяти.
  • Вы сказали, что Тонкий работал хорошо. Вы уже настроили его в конфигурации обратного прокси? Потому что это то, что люди делают в производственных сценариях. Выставлять Thin (или Mongrel, или Unicorn) напрямую в Интернет небезопасно.
  • Возможно, вам будет интересно прочитать параметры сервера Ruby on Rails и обзор архитектуры Phusion Passenger для более подробных пояснений.

Когда дело доходит до масштабируемости, особой разницы нет. Все они очень похожи в продакшене, все они масштабируются примерно одинаково, и любые проблемы, с которыми вы столкнетесь, скорее всего, будут вызваны вашим приложением или Rails. Ну, за исключением WEBrick, который вам действительно не следует использовать в продакшене. Вы можете увидеть разницу в тестах hello world, но это все. При использовании в производственной среде большая часть времени будет проводиться в приложении, поэтому любые незначительные различия в скорости, видимые в тестах hello world, станут совершенно невидимыми.

Хотя есть некоторые тонкости, о которых нужно знать.

  • Phusion Passenger предоставляет функцию, называемую глобальной очередью. Он решает конкретную проблему, подробно описанную в руководстве. . По умолчанию Nginx и Apache проксируют запросы в циклическом режиме, поэтому они страдают от этой проблемы, а Phusion Passenger — нет. Есть способы обойти это, когда Phusion Passenger не используется, но они требуют специальной настройки или установки дополнительных модулей веб-сервера.

  • Модель ввода-вывода может быть важна, а может и не быть, в зависимости от характера вашего приложения. Mongrel, Thin, Unicorn, все они многопроцессорные однопоточные. Это отлично работает для традиционных веб-приложений, которые ищут информацию в локальной базе данных и что-то отображают, но в основном плохо работает для приложений, которые выполняют много вызовов HTTP API или иным образом вынуждены много ждать ввода-вывода. Почему Rails 4 Прямые трансляции — это большое дело подробно объясняет это.

    Phusion Passenger также является многопроцессорным однопоточным, но Phusion Passenger Enterprise поддерживает многопоточность. Phusion Passenger Enterprise — это коммерческий вариант Phusion Passenger с открытым исходным кодом, обладающий множеством функций, полезных для крупномасштабных производственных сред.

  • В больших производственных средах некоторые функции становятся важными, например. последовательные перезапуски, не показывая ничего неправильного при сбое развертывания и т. д. Mongrel, Thin, Unicorn, Phusion Passenger, все они в той или иной степени раскрывают эти функции, но некоторые требуют больше усилий администратора, чем другие. Например, для реализации циклических перезапусков в Mongrel и Thin вам потребуется довольно много шагов в сценариях развертывания. Unicorn требует не так много шагов, но все же значительно. Именно здесь сияет Phusion Passenger Enterprise: он объединяет все эти функции и превращает их в единую опцию конфигурации. Включите эту опцию, и программное обеспечение позаботится обо всем остальном.

Итак, выберите любой вариант, который, по вашему мнению, лучше всего подходит для вашего сценария.

person Hongli    schedule 31.10.2012
comment
отсутствовал в течение довольно долгого времени.. спасибо за отличный ответ.. я начал использовать пассажир + nginx с этого момента.. требования не такие экстраординарные, и, следовательно, масштабируемость не была такой проблемой! еще раз спасибо!! - person brucewayne; 04.11.2012
comment
@Hongli У меня есть приложение Rails, в котором широко используется рубиновый драгоценный камень Faye, который, в свою очередь, широко использует веб-сокеты и комету (длинный опрос HTTP). Другими словами, у меня есть сотни TCP-соединений, которые остаются открытыми в течение длительного периода времени. Различные части сайта используют данные в режиме реального времени. Первоначально я использовал Apache2, но решил перейти на nginx из-за его многопоточности с асинхронным вводом-выводом. Будет ли Passenger работать лучше, чем Thin, в качестве сервера приложений? - person Donato; 11.07.2015
comment
@Donato Если вы используете WebSockets, то Passenger Enterprise (для многопоточности) с Nginx будет работать очень хорошо, как и Thin. Основное преимущество Passenger Enterprise по сравнению с Thin заключается в лучшем инструментарии и лучшей документации. Кроме того, ознакомьтесь с инструкциями по настройке WebSocket. - person Hongli; 13.07.2015

arrow_upward
1
arrow_downward

Проще всего настроить для производства, вероятно, Apache и mod_rails (пассажирский). Если вы хотите использовать новую моду, вы можете попробовать nginx и пассажира.

Для разработки с дворняжкой обычно проще всего работать. Большинство IDE для Windows (RadRails, Netbeans) дают вам возможность использовать Webrick или Mongrel для разработки и позволяют управлять серверами из самой IDE.

Обновить

Четыре варианта

На самом деле есть четыре варианта, плюс WEBrick, но это был бы необычный выбор для рабочего сервера. Примерно в порядке возрастания сложности...

nginx + Mongrel nginx + Passenger Apache + Mongrel Apache + Passenger (существует автономный Phusion Passenger, но на самом деле это nginx + пассажир, скомпилированный вместе, поэтому я не считаю его, хотя для некоторых это может быть хорошим вариантом.)

Затем более крупный сайт может добавить специализированное оборудование уровня 7 (NetScaler, F5, ...) перед серверами.

person Dipak Panchal    schedule 27.10.2012
comment
спасибо за ответ .. это больше не для целей разработки .. я думаю, что попробую nginx .. есть понимание по второму вопросу ..? - person brucewayne; 27.10.2012
comment
Я не согласен с вашей сортировкой по порядку сложности. Phusion Passenger + Apache и Phusion Passenger + Nginx имеют примерно одинаковую сложность с точки зрения удобства использования. Но оба менее сложны с точки зрения удобства использования, чем Apache/Nginx + Mongrel. Phusion Passenger Standalone должен быть самым простым из всех, потому что это всего лишь одна команда, нет необходимости самостоятельно компилировать Nginx, а результат можно сразу же опубликовать в Интернете. Кроме того, Phusion Passenger + Nginx не является новой модой — она существует с 2009 года. - person Hongli; 31.10.2012

arrow_upward
0
arrow_downward

Тонкий так же прост, как драгоценный камень, «тонкий» для разработки и производства

person Nick Ginanto    schedule 29.10.2012