Рекомендации по масштабированию на платформе Heroku

Question

Я запускаю приложение на основе NodeJS, подключенное к mongohq-MongoDB, на бесплатно Dyno. Я хотел бы перенести его на использование хобби Dyno, и мотивация сделать это не только во время сна, но и для обеспечения более высокой пропускной способности HTTP-трафика.

Прочитав документацию Scaling и статью Procfile, я смутился о том, как следует масштабировать по Heroku.

В Procfile статье говорится, что веб тип процесса является единственным процессом, который будет получать HTTP трафик от Heroku маршрутизации меш.

Так что мои вопросы:

1. Когда есть уже один хобби Dyno работает, выполняя «Heroku пс: масштаб веб + 2» приведет в том, +2 веб-процессов на том же Dyno или в добавлении два хобби Dynos (в общей сложности три увлечения Dynos)?
   • Всего три хобби Dynos означает 3 веб-процесса и 27 не-веб-процессов?
2. В this ответ, он предложил использовать кластер модуль раскошелиться потоков для обработки HTTP-запросов, как можно определить # работников, которые должны быть созданы (в цикле // fork worker processes)?
3. Как я должен решить, когда масштабировать мое приложение по горизонтали (добавить динамометрические стенды одного и того же типа) вертикально (сильнее динамометрические стенды как стандарт-1X/2X)
   • Горизонтальная шкала должна быть запущена для обработки более высокой # запросов ?
   • Вертикальная шкала должна быть запущена для обработки тяжелее обработки (больше вычислительных ресурсов в необходимости предоставления ответа на соответствующий запрос?)

NB,

В Scaling раздел this ответ, результат Dynos по-прежнему не ясен в отношении вопроса № 1 выше.

---

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

Answer 1

Я возьму их в порядке ...

1. Нет, у вас есть 10 типов процессов в ярусе хобби, это означает, что если у вас есть 1 веб-дино, вы можете иметь еще 9 динамометрические стенды работает для того же приложения, эти 9 могут быть любой записи в вашем файле Procfile.

   У вас может быть только один веб-динамо, остальные - другие (до 9) записей в вашем Procfile.

2. Это в основном диктуется памятью, это зависит от того, что вы делаете в приложение, если оно достаточно мало, то вы можете запустить более, Node.js кластер рабочих отдельные процессы Node.js, которые происходят для совместного использования одного и того же сокета, а ОС распределяет запросы по процессам.

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

Что определяет "медленный" запрос?

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

Горизонтальная шкала и вертикальное масштабирование совершенно разные, и ответ на это зависит от вашего приложения, большие динозасы имеют больше памяти, а это значит, что они могут кэшировать данные в памяти или обрабатывать большую полезную нагрузку из внешних сервисов, а также производительность -M и Performance-I «предназначены» для клиента, поэтому вы получите более предсказуемые профили нагрузки.

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

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