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

Question

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

http://www.heroku.com/pricing

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

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

Answer 1

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

Вы ищете записи 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 для входящих запросов.

Answer 2

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

Answer 3

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

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

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

Answer 4

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

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

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

Answer 5

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

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

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