Тонкий против Единорога на Хереку

Ответ 1

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

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

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

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

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

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

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

Ответ 2

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

Яростно пылает даже с 1 динамиком, и падение времени отклика ощутимо. Простой Пассажирский Ruby Heroku Demo размещен на github.

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

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

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

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

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

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

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

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

Ответ 3

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

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

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

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

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

К сожалению.