Что лучше использовать для параллельного выполнения nodejs и нужно ли это вообще в моем случае?

Question

[Иван Иванов]

Вводные
Есть приложение на nodejs которое слушает веб-сокет. При получении сообщений, в зависимости от содержимого, запускаются следующие модули (1) в которых начинается прослушка своих сокетов. В каждом таком модуле происходит много http запросов к апи. Вычислений сложных в целом нет, никаких сортировок или прям блокирующих операций нет (только в некоторых местах встречаются for() циклы, в которых внутри await, но такие функции запускаются асинхронно)
Т.е. можно понять, что одно из самых узких мест - сеть.
Node и другие сервисы (redis, mysql...) крутятся в докере в своих контейнерах
Сам node скрипт запускается через forever, что бы перезапускаться при краше.
Данные между этими подпроцессами передавать не нужно. Но вот получить данных из родительского процесса хотелось бы (но можно и через редис все устроить, если это действительно нужно)

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

Вопрос

1. Имеет ли вообще смысл в моем случае использовать распараллеливание или все равно все упирается в сеть и я не добьюсь быстродействия? (с учетом что операция сложных нет, но их многовато)
   
2. Если это все крутится в докере, он же сам умеет в многопоточность, верно?
   
3. Влияет ли как то на многопоточность forever (можно и на pm2 переехать, но пока хватало forever)
   
4. Ну и главный вопрос. Если все таки имеет смысл в распараллеливании, что лучше использовать? child_process, Worker_threads, cluster. На сколько я понимаю, мне лучше всего подходит cluster, т.к. не нужно общаться между дочерними потоками, но желательно иметь связь с родительским потоком.
   
5. И еще момент. Если крешнится какой-либо дочерний поток, это приведет к крешу всего приложения и других потоков или же родительский процесс так и продолжить работать запуская новые дочерние?
   

Comments

[VoidVolker]

Иван Иванов А какие вы провели исследования вашей проблемы и в чем именно она заключается? Вы нашли ваше бутылочное горлышко? Провели более детальное его исследование и выявили конкретное место/причину? Каким образом и по каким критериям вы определили, что проблема именно в сети и и почему для её устранения надо запускать запускать дополнительные потоки?

[Иван Иванов]

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

Исследовать вот только начал, т.к. набралось данных во время работы и в целом есть объемы на которых можно что-то понять.
Буду пытаться понять, все таки в сети проблема или же где-то не успевает отрабатывать скрипт.

Предположил сеть в первую очередь, т.к. задачи в скриптах простые, в основном получить сообщение, распарсить, и отправить много запросов к стороннему апи.

А можно ли устранить проблемы с сетью с помощью потоков, собственно вопрос и есть.

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

[VoidVolker]

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