Webrick как производственный сервер против Thin или Unicorn?

117

Кажется само собой разумеющимся, что вы не должны использовать Webrick в качестве рабочего сервера, но я не могу найти где-либо упоминания почему. Похоже, что консенсус таков: «Webrick подходит для разработки, но Thin или Unicorn - выбор для производства, точка».

Я просмотрел домашнюю страницу тонкого сервера, и там говорится о запросах в секунду, но я не очень понимаю график, так как там нет аннотации.

Может ли кто-нибудь сообщить мне, почему я должен использовать Thin или Unicorn по сравнению с Webrick? Также есть ли польза от использования Webrick для разработки? Я использую Webrick с тех пор, как он поставляется с направляющими, и я думаю, что должна быть причина, почему он используется по умолчанию.

Кстати, я использую Heroku.

ruby-on-rails production-environment thin webrick unicorn Влад
источник
Это медленно по сравнению с другими, такими как Mongrel.
uday 02
38
Кен, я действительно не задавал этот вопрос для обсуждения чего-либо. Я искренне хочу знать ответ, потому что я нигде не мог найти настоящую статистику, когда все считают само собой разумеющимся, что Webrick уступает. Я не связан ни с одной из этих партий, и упомянутые вами дебаты - это вопросы, которые я задаю из искреннего любопытства. Как я могу перефразировать вопрос, чтобы это выглядело иначе?
Влад
24
Это хороший вопрос.
Justingordon
29
Подобные вопросы НЕ следует закрывать. Они полезны и полезны. Вся самозваная контентная полиция должна отступить.
Кен Смит
22
Я нашел это, погуглив "Почему бы не использовать WEBrick в производстве?" потому что это вопрос, на который я хочу получить ответ. Я не хочу использовать WEBrick в производстве, но меня раздражает то, что все говорят: «Очевидно, потому что это не для Production®». На самом деле это не так очевидно - если бы это было так, люди не стали бы исследовать вопрос, пока наконец не задали его в StackOverflow, как указывает @Vlad. Принятый ответ полезен; по крайней мере, указывает на некоторые недостающие функции. По касательной, настаивать на закрытии вопроса, потому что вы считаете его спорным, без вашего собственного ответа бесполезно.
Justin Force

Ответы:

42

Пара важных причин

  1. он написан на Ruby (см. http://github.com/ruby/ruby/tree/trunk/lib/webrick )
  2. Отредактированный, он не имеет многих функций, которые обычно нужны производственному веб-сайту, таких как несколько рабочих (в частности, предварительный форк, управление жизненным циклом, асинхронная обработка и т. Д.), Перенаправления, перезапись и т. Д.

Когда я упоминаю перенаправления / перезапись, я имею в виду тот факт, что при использовании Webrick вы должны обрабатывать перезапись на другом уровне (Rack, Sinatra, Rails, пользовательский код Webrick и т. Д.). Это требует от вас запуска дополнительных рубиновых «обработчиков» для выполнения вашего кода перезаписи. Для сайта с низким трафиком это может быть нормально, поскольку у вас могут быть предварительно нагретые процессы, которые уже ничего не делают. Однако для сайта с более высоким трафиком это дополнительная нагрузка на сервер из-за того, что серверы переднего плана (Apache, Nginx и т. Д.) Могут справиться без раскрутки Ruby * и, вероятно, на несколько порядков быстрее.

* например, если вы работаете за балансировщиком нагрузки, вы можете направить весь перезаписанный трафик на сервер, на котором не установлен Ruby, и позволить вашим основным серверам управлять только основным трафиком. Этот трафик перезаписи может быть связан с изменениями сайта для SEO или чем-то подобным. Другим случаем может быть сайт, который имеет несколько компонентов, и, возможно, один раздел - это Rails, другой - PHP, и для обоих необходимы перезаписи (т.е. переписать старые пути PHP на Rails)

Джим Девиль
источник
Разве нельзя использовать delayed_job для обработки нескольких воркеров на Heroku, независимо от того, какой сервер вы используете?
Влад
Да, delayed_job не имеет отношения к Webrick, если только ваши задания не используют API-интерфейсы Webrick (честно говоря, это запах кода, когда он соединяется).
Джим Девиль
Я имею в виду перенаправления за пределами стека Ruby. Как и перенаправления в стиле mod_rewrite. Технически вы можете перенаправить внутри Rack, или Rails, или, может быть, даже Webrick (я могу ошибаться), но для этого требуется запуск Ruby, который сравнительно медленный по сравнению с Apache или Nginx
Джим Девиль
1
@JimDeville - Unicorn также написан на Ruby
Yarin
1
github.com/defunkt/unicorn/tree/master/ext/unicorn_http большая часть Unicorn находится в C
Джим Девиль
4

WEBrick также не может обрабатывать более длинные URI, если они превышают 2083 символа, вы увидите сбой. У Thin нет этих проблем, что делает его превосходным - он уже находится в разработке.

Михаэль Шмитц
источник
Также Webrick потерял соединение и автоматически отключился, когда, по моему опыту, я занимаюсь разработкой программного обеспечения, и когда я выбрал WeBRICK в Heroku PaaS, автоматическое отключение компенсируется высокой скоростью автоматического включения (запускается через автоматическую архитектуру Heroku )
Даниэль Антонио Нуньес Каруайо
3

Не очень люблю усложнять простые вещи и преждевременную оптимизацию. WEBrick можно использовать в продакшене, если это веб-сайт с низкой посещаемостью. Большинство приложений есть.

Если ваш сайт делает что-то, что требует времени, например, отправляет электронные письма или создает файлы PDF, вам следует сделать WEBrick многопоточным . Вы хотите обрабатывать несколько запросов одновременно.

Nowaker
источник
1

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

Бретт Хеннинг
источник
4
Вы видели сравнение статистики? Я также слышу, как люди говорят это (и, вероятно, это правда), но я не могу найти реального сравнения статистики где-либо в Интернете ...
Влад
3
Я не думаю, что кто-то действительно тестирует Webrick, потому что он не предназначен для использования в качестве производственного сервера. Unicorn, Thin или Passenger - это хорошая поддержка и гораздо лучшие варианты
Джим Девиль
0

Самая большая слабость webrick при работе в производственном режиме заключается в том, что это однопоточный однопроцессный веб-сервер, что означает, что он способен одновременно обслуживать только один-единственный HTTP-запрос.

Артур Беляев
источник
Это не однопоточный. Или это так же, как реализуется любой современный скриптовый язык (с GIL). Но доступ к базе данных и ввод-вывод в webrick полностью многопоточный.
Lothar