Я не понял каким образом он там что-то ускорил методом разнесения по процессам, ведь количество ресурсов для выполнения работы не уменьшилось а даже увеличилось из-за накладных расходов на 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? Или лучше само приложение полностью копировать средствами снаружи и запускать инстансы? Если мы хотим все ядра загрузить.
"node такая быстрая за счет того что все выполняется в одном потоке" - слишком уж вы сильно исказили услышанную где-то мысль, либо невнимательно воспринимаете информацию
Просто люди не умеют или не хотят формулировать мысли грамотно. Здесь имеется ввиду, что Node.js имеет преимущество не потому, что она однопоточная, а потому, что она создает один поток, не роняет его, и обрабатывает все запросы в нем. Из-за этого сервер быстро отвечает, так как не тратит время на порождение потока, как в PHP например. Разумеется на любом языке программирования, распараллеливание увеличивает производительность.
У большинства докладчиков почти всегда одна тема с которой они выступают по всему миру много раз. И с каждым новым выступлением они приходят к пониманию, что есть вещи сказанные хорошо, и хочется повторить их еще раз слово в слово.
Полтора месяца назад я почти ничего не понимал. Сейчас смотрю, и понятно почти всё. Приятно что моё самостоятельное обучение даёт плоды))
спасибо, очень доходчиво и структурировано:)
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? Или лучше само приложение полностью копировать средствами снаружи и запускать инстансы? Если мы хотим все ядра загрузить.
нее, это явно не мой уровень
Хороший доклад
node такая быстрая за счет того что все выполняется в одном потоке. Как ускорить node ? распаралелить ноду )))))) чтото ржу я над всем эти )))
"node такая быстрая за счет того что все выполняется в одном потоке" - слишком уж вы сильно исказили услышанную где-то мысль, либо невнимательно воспринимаете информацию
Просто люди не умеют или не хотят формулировать мысли грамотно. Здесь имеется ввиду, что Node.js имеет преимущество не потому, что она однопоточная, а потому, что она создает один поток, не роняет его, и обрабатывает все запросы в нем. Из-за этого сервер быстро отвечает, так как не тратит время на порождение потока, как в PHP например.
Разумеется на любом языке программирования, распараллеливание увеличивает производительность.
Уже практически в 2024 актуально хоть?)
Да конечно
+
Слишком заученный текст, бросается в глаза
Слишком хорошо подготовился докладчик? Должен был побольше ошибаться и мямлить?
Гитарист слишком сильно заучил партию, бросается в глаза
Вы как никогда не выступали - там же телесуфлёр снизу.
У большинства докладчиков почти всегда одна тема с которой они выступают по всему миру много раз. И с каждым новым выступлением они приходят к пониманию, что есть вещи сказанные хорошо, и хочется повторить их еще раз слово в слово.
Ору, как ни сделай, скажут дурак