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

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

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

http://www.heroku.com/pricing

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

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

Ваш лучший индикатор, если вам нужно больше динамометров (также известных как процессы в 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 для входящих запросов.

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

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

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

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

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

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

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

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

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

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