Тонкий против Единорога на Heroku

Просто хотел узнать мнение людей об использовании Unicorn vs Thin в качестве сервера rails. Большинство статей / тестов, которые я нашел в Интернете, кажутся очень неполными, поэтому было бы неплохо иметь централизованное место для их обсуждения.

Unicron- это многопроцессорный сервер, а thin - сервер, основанный на событиях / не блокирующий. Основанные на событиях серверы хороши... если ваш код асинхронный / неблокирующий - ванильные рельсы блокируют. Поэтому, если вы не используете неблокирующие рельсовые библиотеки, я действительно не вижу преимущества использования Thin. Что еще хуже, на неблокирующем сервере, если ваш цикл ввода-вывода блокируется, вы собираетесь заблокировать весь цикл и не сможете обрабатывать больше запросов до тех пор, пока не завершится блокирующий вызов. Блокировка библиотек замедлится!

Почему Heroku выбрал Thin в качестве сервера по умолчанию (для кедра)? Они умные ребята, поэтому я уверен, что у них была причина.

Сильфон - это ссылка, которая предлагает заменить Thin на 4 рабочих Unicorn - для меня это имеет смысл. 4 рабочих Unicron на Heroku

3 ответа

Thin легко настроить - не оптимально, но он работает только в среде Heroku.

Единорог может быть более эффективным, но его необходимо настроить: сколько работников? Предварительная загрузка приложения? Что вы выбираете?

Я выпустил приложения Unicorn Heroku с рабочими, настроенными на 3, 5 и 8 - только в зависимости от того, насколько велико каждое приложение - сколько кода, сколько памяти используется и сколько трафика вы получаете, чтобы собрать этот номер, и вам нужно проводить мониторинг с течением времени, чтобы убедиться, что вы правильно поняли номер, а вашему приложению не хватает памяти.

Preload false - это замедлит запуск вашего приложения, но когда Unicorn перезапускает работника, это "безопаснее" с сетевыми подключениями (memcache, postgres, mongo и т. Д.)

Preload true - это лучше, но вам нужно правильно обрабатывать повторные соединения с сервером в коде pre и post fork.

У Thin нет ни одной из этих проблем из коробки, но вы получаете только процесс выполнения.

Резюме: действительно сложно настроить Unicorn из коробки, чтобы он работал хорошо (или вообще) для всех, тогда как Thin может просто работать, чтобы заставить людей работать с меньшим количеством запросов поддержки.

Недавно (всего несколько месяцев назад) ребята из Phusion Passenger добавили поддержку Heroku. Определенно, это альтернатива, которую вы должны попробовать и посмотреть, соответствует ли она вашим потребностям.

Горит быстро даже с 1 динамо, и время отклика ощутимо. Простая демонстрация Passenger Ruby Heroku размещается на github.

Основные преимущества, которые Пассажиры заявляют в Heroku:

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

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

  • Оптимизация памяти - Phusion Passenger использует меньше памяти, чем Thin и Unicorn. Он также поддерживает виртуальную память с копированием при записи в сочетании с предварительной загрузкой кода, что позволяет вашему приложению использовать еще меньше памяти при работе на Ruby 2.0.

  • Буферизация запросов / ответов - включенный Nginx буферизует запросы и ответы, тем самым защищая ваше приложение от медленных клиентов (например, мобильных устройств в мобильных сетях) и улучшая производительность.

  • Внеполосный сборщик мусора - сборщик мусора в Ruby работает медленно, но зачем беспокоить ваших посетителей долгим временем ответа? Исправьте это, запустив сборку мусора вне обычного цикла запрос-ответ! Эта концепция, впервые представленная Unicorn, была улучшена: Phusion Passenger гарантирует, что только один запрос одновременно выполняет внеполосную сборку мусора, таким образом устраняя все проблемы, возникающие во внеполосной сборке мусора Unicorn.

  • Поддержка JRuby - Unicorn - лучший выбор, чем Thin, но он не поддерживает JRuby. Phusion Passenger делает.

Надеюсь это поможет.

Heroku не использует интеллектуальную маршрутизацию - она ​​случайным образом назначает задания для динамометров независимо от того, занят ли динамометрический прием. Таким образом, если ваш dyno не может обрабатывать несколько заданий одновременно, вы получите задержку (возможно, огромную задержку), даже если вы платите за множество других бесплатных dyno. "Правильно - если вашему приложению нужно 80 дин с интеллектуальным маршрутизатором, ему нужно 4000 с произвольным маршрутизатором". http://news.rapgenius.com/James-somers-herokus-ugly-secret-lyrics

Heroku говорит, что они работают над этим, и их план состоит в том, чтобы упростить использование Unicorn. Они в основном сказали: "Ой, мы не заметили, что это было проблемой в течение нескольких лет... и теперь, когда мы смотрим, это определенно проблема для Тонких... так что я думаю, вам нужно использовать другую программу, чем тот, который мы давили все это время. " http://news.rapgenius.com/Jesper-joergensen-routing-performance-update-lyrics

Из официального объяснения Heroku (вторая ссылка выше): "На самом деле Rails еще не надежно поддерживает параллельную обработку запросов. Это делает разработчиков Rails неспособными использовать дополнительные возможности параллелизма, предлагаемые стеком Cedar, если они не переходят в параллельную сеть". сервер как пума или единорог.

Приложения Rails, развернутые в Cedar с Thin, могут довольно быстро столкнуться с проблемами в очереди запросов. Поскольку маршрутизатор Cedar больше не создает очередей от имени приложения, запросы, находящиеся в очереди в dyno, должны ждать, пока отдельный процесс Rails не пройдет через очередь. Многие клиенты столкнулись с этой проблемой, и мы не смогли принять меры и предоставить им лучший подход к развертыванию приложений Rails на Cedar ".

Также интересно то, что их инструменты производительности, включая New Relic, не сообщают о времени, проведенном в очереди dyno. http://news.rapgenius.com/Lemon-money-trees-rap-genius-response-to-heroku-lyrics

К сожалению.

Другие вопросы по тегам