Николай Матвиенко - Декомпозиция Main Thread в Node.js для увеличения пропускной способности
Vložit
- čas přidán 28. 10. 2018
- Ближайшая конференция - HolyJS 2024 Autumn, 7 ноября (online), 14-15 ноября (Санкт-Петербург + трансляция).
Подробности и билеты: jrg.su/K18Cxd
- -
. . Опытный Node.js-разработчик, обладает большим багажом знаний по созданию и поддержке высоконагруженных систем на Node.js
Рост функциональности в Enterprise Node.js приложениях часто приводит к снижению пропускной способности. В этом докладе мы начнем с дисперсии Main Thread (основного потока Node.js) и разложим его на спектр выполняемых в нем операций. Узнаем, какие из этих операций мы можем перенести в отдельные потоки/воркеры/процессы и как это сделать. Мы выберем успешные способы распараллеливания для каждого типа операций, рассмотрим их преимущества и ограничения. Помимо стандартных способов мы также рассмотрим альтернативные решения распараллеливания задач используя возможности V8 и libuv thread pool. В завершение сравним как архитектура приложения и пропускная способность изменились после декомпозиции Main Thread. - Věda a technologie
Полтора месяца назад я почти ничего не понимал. Сейчас смотрю, и понятно почти всё. Приятно что моё самостоятельное обучение даёт плоды))
спасибо, очень доходчиво и структурировано:)
p.s. было бы здорово прикладывать к видео ссылки которыми делится докладчик
Хороший доклад
Классный доклад!
Я не понял каким образом он там что-то ускорил методом разнесения по процессам, ведь количество ресурсов для выполнения работы не уменьшилось а даже увеличилось из-за накладных расходов на IPC , в его схеме прирост может быть только если у на есть свободные ядра или же в коротких пиках нагрузки когда все накладные расходы в стиле fire and forget
RPS - это не совсем про скорость, а скорее про объём. Один поток с Event Loop может обрабатывать грубо говоря, одновременно несколько запросов, но туда же идут все промисы, тем самым забивая Event Loop, очередь промисов в котором ограничена. И разбиением на процессы мы освобождаем в нашем главном потоке event loop и тем самым даём ему меньше работы и больше места в очереди промисов, что позволяет обработать больше запросов в этом главном потоке. В общем пытаются реализовать условный Thread Pull, как в Java,/C#, но только очень костыльно. Использование Thread Pull (и похожих схем многопоточной и многопроцессорной работы) в любом случае несёт за собой временные издержки на обработку запроса, но по итогу мы можем их обработать больше, чем без него. А наличие свободного ядра (а ещё точнее процессорных потоков), конечно, обязательно. В одноядерной системе прирост хоть и будет, но не такой, чтобы ради него так заморачиваться.
@@hgfyos так в том то дело что прирост будет только при наличии свободных ядер cpu и при таком раскладе гораздо эффективнее поднять на этих ядрах инстансы основного процесса
@@vladimirkrasulya8693 создать поток дешевле, чем создать инстанс, тем более если потребуется это сделать динамически. Да и помимо процессорных потоков, мы же можем пользоваться виртуальными. Собственно тут и суть в том, что мы выделяем потоки по мере потребностей и не мы занимаемся балансировкой нагрузки между ними. Но в докладе представлены довольно костыльное решение (да и других решений пока нет), из-за чего всё же действительно проще просто поднять инстансы. Надо ждать официально в ноде Thread Pull Manager
@@hgfyos А есть выгода использовать cluster? Или лучше само приложение полностью копировать средствами снаружи и запускать инстансы? Если мы хотим все ядра загрузить.
+
нее, это явно не мой уровень
Уже практически в 2024 актуально хоть?)
Да конечно
node такая быстрая за счет того что все выполняется в одном потоке. Как ускорить node ? распаралелить ноду )))))) чтото ржу я над всем эти )))
"node такая быстрая за счет того что все выполняется в одном потоке" - слишком уж вы сильно исказили услышанную где-то мысль, либо невнимательно воспринимаете информацию
Просто люди не умеют или не хотят формулировать мысли грамотно. Здесь имеется ввиду, что Node.js имеет преимущество не потому, что она однопоточная, а потому, что она создает один поток, не роняет его, и обрабатывает все запросы в нем. Из-за этого сервер быстро отвечает, так как не тратит время на порождение потока, как в PHP например.
Разумеется на любом языке программирования, распараллеливание увеличивает производительность.
Слишком заученный текст, бросается в глаза
Слишком хорошо подготовился докладчик? Должен был побольше ошибаться и мямлить?
Гитарист слишком сильно заучил партию, бросается в глаза
Вы как никогда не выступали - там же телесуфлёр снизу.
У большинства докладчиков почти всегда одна тема с которой они выступают по всему миру много раз. И с каждым новым выступлением они приходят к пониманию, что есть вещи сказанные хорошо, и хочется повторить их еще раз слово в слово.
Ору, как ни сделай, скажут дурак