Узел child_process vs Heroku worker

Question

Попытка разобраться с рабочими против потоков на узле и в Хероку. Что происходит, когда вы вызываете exec из Node.js?

Правильно ли считать, что это работает в отдельном потоке и не блокирует цикл основного события?

require('child_process').exec(cmd, function (err, stdout, stderr) { 
     // ... do stuff   
    }); 

Если на Heroku есть ли преимущество переместить это отдельному работнику? Например.

• Если вычислительная интенсивность, будет ли child_process замедлить основное приложение?
• У рабочих динозавров есть собственный лимит памяти?
• Будет ли непроверенная ошибка (не дай бог) не разбивать основное приложение, если у работника?

Answer 1

В узле дочерний процесс представляет собой отдельный отдельный процесс на процессоре, который является дочерним элементом вашего родительского процесса (ваш сценарий Node.js). Эта статья объясняет это в гораздо большей глубине здесь: http://www.graemeboy.com/node-child-processes

Что это означает на Heroku, является то, что если вы используете child_process, чтобы породить новый дочерний процесс, ваш Heroku дино будет на самом деле быть в состоянии сделать «больше» общую работу процессора, поскольку он будет запускать ваш код дочернего процесса (скорее всего) на отдельном физическом ЦП (это в значительной степени зависит от множества факторов в вашем приложении).

Это может быть проблемой, поскольку каждый из процессоров Heroku имеет ограниченное количество ресурсов ЦП и ОЗУ.

Так, например, если ваш код Dyno (веб-бит, а не отдельный работник Heroku) интенсивно работает с CPU и использует child_process, вы будете использовать все ресурсы вашего процессора, и ваш код начнет блокировать/висеть в узле.

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

Мне лично нравится использовать службу массового обслуживания, такую ​​как Amazon SQS, для обработки передаваемых данных между моими веб-динамиками и моими рабочими динамиками, так как это супер быстро недорого, но у вас много вариантов.

Каждый динамик, который вы создаете (веб-динозавры и рабочие динамометры), получает свои собственные ресурсы, поэтому каждый динамометр получает свое собственное количество CPU и оперативной памяти. Типы доступных динамиков и их пределы ресурсов и поясняются здесь: https://devcenter.heroku.com/articles/dyno-types

Что касается обработки ошибок, если вы не поймаете исключения, сложно сказать, что произойдет. Однако очень возможно, что ваше приложение Node сработает (а затем Heroku просто перезапустит его). Это действительно зависит от вашей конкретной реализации различных вещей =/