Heroku: веб-дино против рабочего дино? Сколько / какое соотношение мне нужно?

82

Мне было любопытно, в чем разница между веб-динамометрами и рабочими модулями на Heroku. Они дают объяснение одним предложением на своей странице с ценами, но это меня просто сбивает с толку. Как мне узнать, сколько выбрать каждого? Есть ли соотношение, к которому я должен стремиться? Я новичок в этом вопросе, поэтому может ли кто-нибудь дать подробное объяснение или, может быть, каким-то образом я могу вычислить, сколько и какого типа динамометрические установки мне понадобятся?

Кроме того, я не понимаю, что они подразумевают под количеством часов для каждого дино.

http://www.heroku.com/pricing

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

http://devcenter.heroku.com/articles/backlog-too-deep

варатис
источник

Ответы:

58

Ваш лучший индикатор, если вам нужно больше динамометров (также известных как процессы в Cedar), - это ваши журналы heroku. Убедитесь, что вы перешли на расширенное ведение журнала (это бесплатно), чтобы вы могли следить за своим журналом.

Вы ищете записи heroku.router, и значение, которое вас больше всего интересует, - это значение очереди - если оно постоянно больше 0, это хороший знак, что вам нужно добавить больше динамометрических станций. По сути, это означает, что поступает больше запросов, чем ваш процесс может обработать, поэтому они ставятся в очередь. Если они находятся в очереди слишком долго, не возвращая никаких данных, время ожидания истечет.

Боюсь, что нет идеального соотношения, у вас может быть приложение, выполняющее 100 запросов в секунду, требующее множества веб-процессов, но просто не использующее рабочих. Рабочие процессы нужны только в том случае, если вы выполняете обработку в фоновом режиме, например отправку писем и т. Д.

ps Слишком глубокое отставание может стать причиной этого веб-процесса Dyno.

ОБНОВЛЕНИЕ: 26 марта 2013 года Heroku удалила поля очереди и ожидания из записи выхода.

Поля очереди и ожидания были удалены из сообщений журнала маршрутизатора. Кроме того, маршрутизатор Heroku больше не устанавливает HTTP-заголовки X-Heroku-Dynos-In-Use, X-Heroku-Queue-Depth и X-Heroku-Queue-Wait-Time для входящих запросов.

Джон Бейнон
источник
12
Чтобы посмотреть логи маршрутизатора heroku, сделайтеheroku logs -p router --tail
Натан Херст
1
Я не вижу значение очереди, я вижу dyno = web.1 connect = 2ms service = 4ms status = 200 байт = 43
Jaqx
8
Почему они их удалили?
Аттилио
6
Вы по-прежнему можете получить эту информацию, включив надстройку Heroku Labs log-runtime-metrics. Для этого выполните следующую команду heroku labs:enable log-runtime-metrics. Подробнее читайте здесь: devcenter.heroku.com/articles/log-runtime-metrics
Джереми Фокс,
3
stackoverflow.com/a/19965981/1233555 - Heroku перешел на случайную маршрутизацию, поэтому у некоторых дино могут складываться очереди, в то время как другие дино свободны. Избегайте этого, убедившись, что все запросы обрабатываются очень быстро в ваших веб-серверах.
ChrisPhoenix
15

Dynos - это в основном процессы, которые выполняются на вашем экземпляре. С новым стеком Cedar их можно настроить для выполнения любой произвольной команды оболочки. Для веб-приложений у вас обычно есть один процесс, называемый «веб», который отвечает за HTTP-запросы от пользователей. Все остальные процессы - это то, что раньше называли «рабочими». Они работают постоянно в фоновом режиме для таких вещей, как cron, очереди обработки и любые тяжелые вычисления, которые вы не хотите связывать с вашими веб-процессами. Вы также можете масштабировать каждый тип процесса, чтобы несколько процессов каждого типа были загружены для дополнительного параллелизма. Количество каждого из них, которое вы используете, действительно зависит от потребностей вашего приложения и нагрузки, которую оно получает. Вы можете использовать такие инструменты, как плагин New Relic, чтобы отслеживать эти вещи.

Джимми Куадра
источник
1
«Dynos - это в основном процессы, которые выполняются на вашем экземпляре». Это неверное утверждение. Dyno существуют в разных экземплярах.
Нил Миддлтон
9

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

Затем вы разработали бы автономный рабочий дино (ы), который будет обслуживать эту очередь. Они могут занять намного больше времени, потому что на их выходе нет ожидающих HTTP-ответов. Возможно, страница, которую вы визуализировали из первоначального запроса браузера, который подтолкнул действие, будет обслуживать некоторый Javascript, который запускает поток, который проверяет, завершился ли запрос каждые 5 секунд, или что-то в этом роде.

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

эблюм
источник
3

https://stackoverflow.com/a/19965981/1233555 - Heroku перешел на случайную маршрутизацию, поэтому у некоторых динамометрических станций могут складываться очереди (пока они обслуживают длинный запрос), в то время как другие динамометрические станции бесплатны. Избегайте этого, убедившись, что все запросы обрабатываются очень быстро в ваших веб-серверах. Это уменьшит количество необходимых вам веб-дино, но при этом потребует больше рабочих дино.

Вам также необходимо позаботиться о том, чтобы ваше веб-приложение поддерживало параллелизм, что есть только в некоторых конфигурациях Rails - попробуйте Unicorn или тщательно написанный код (для ввода-вывода, который не блокирует EventMachine) с помощью Thin.

Вероятно, вам придется попробовать, а не рассчитывать, сколько динамометрических модулей каждого типа вам нужно. Убедитесь, что их New Relic сообщает о очереди дино - см. Ссылку выше.

ChrisPhoenix
источник
1

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

Как описывает Джон, если вы начинаете видеть очередь в своих журналах, вам нужно больше дино. Если вы начинаете видеть, что ваши фоновые очереди становятся слишком длинными (способ получения этой информации зависит от того, что вы реализовали), вам нужно больше рабочих.

Нет никакого соотношения, поскольку оно очень сильно зависит от дизайна и использования вашего приложения.

Нил Миддлтон
источник
1
Хорошо спасибо. Я предполагаю, что под дино вы имеете в виду веб-дино. Кроме того, как мне проверить наличие очереди в моем журнале? Более конкретно, я спрашиваю, как мне определить, накапливаются ли вещи, когда я читаю свой журнал? Я разработчик Rails, поэтому часто имею дело с запуском локального сервера и чтением этих журналов, но не уверен, что смогу определить очередь, если бы увидел ее.
varatis
1
мой ответ описывает, как определить размер очереди - следите за тем, чтобы вы входили в систему на heroku и ищите записи маршрутизатора и значение queue =. Ваши локальные журналы вам не помогут - вам нужно использовать heroku logs -fиз командной строки.
Джон Бейнон
1
@JohnBeynon Хорошо, спасибо. Не осознавал этого, пока не перечитал позже.
varatis