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

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

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

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

Я использую Heroku, кстати.

Ответ 1

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

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

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

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

Ответ 2

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

Ответ 3

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

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

Ответ 4

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

Ответ 5

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