Комментарии 18

Поддерживаю, разве только бесполезных гифок можно было по-меньше вставить, 0 например.

Перейдите к оригинальной версии, и уважайте чужой труд по их переносу.
вообще то сейчас уже все многопоточное и доступ к файлам тоже, базе
а вы статью точно внимательно читали? JS однопоточный, но неблокирующий ввод-вывод реализован путём запуска отдельных потоков (threads) через средства ОС, соответственно вся работа с сетью и файлами и запускается в отдельных потоках.
Вот это кстати непонятный момент. Потоков в ноде для IO вроде как нет, но это только с точки зрения прикладного программиста. На самом деле под капотом какие-то потоки в ОС на каждую IO-операцию формируются. Не получаем ли мы те же самые N потоков на N запросов только скрытно?
Для I/O используется пул потоков, размер которого ограничен по-умолчанию 4-мя потоками, соответственно одновременно может выполняться только 4-ре I/O операции, остальные встают в очередь, так что это потенциальное узкое место. При необходимости размер пула можно увеличить. И не для всех операций этот пул используется, если внешний API поддерживает неблокирующий ввод-вывод, то пул не нужен.
Спасибо, здесь действительно содержатся те факты про nodejs и worker threads, которые надо держать в уме, если хочется сконструировать на nodejs что-то более или менее нагруженное. Правда, для тех, кто интересуется платформой, эти факты, скорее всего, не будут новостью.

Тем не менее, совсем недавно мне рассказывали, что неблокирующим образом nodejs умеет обращаться только к MongoDB, а когда используются «старые» реляционные БД (Oracle, Postgres), то обращение к ним из nodejs все равно блокирует поток, потому что для них нету асинхронных неблокирующих драйверов (какие есть для монги). Может быть, кто-нибудь из экспертов откомментирует, так это или не так?
Не работал с монгой, так что не дам комментариев по её поводу, но вот утверждение о том, что Оракл или постгрес блокируют поток — однозначно ложный. Если бы это было так, то применение этих СУБД с нодой было бы невозможным :)

Если внешняя система не поддерживает неблокирующий I/O, нода использует пул потоков, о котором в статье как раз говорится.
Почему-то вспомнилась реализация многозадачности в win 3.1 (или 95, но в меньшей мере) и та же беда с CPU ёмкими задачами, а появление модуля Worker Threads говорит том, что чуда не произошло.
Собственно, а существуют ли исследования о том, на сколько подобная экономия на «переключении задач» эффективна? Вот почему-то мне кажется, что значительное количество одновременно обслуживаемых клиентов у Node будет, если эти клиенты в основной массе простаивают (затраты на переключение задачи в многопоточной реализации сопоставимы с затратами на выполнение полезного действия), но в случае, когда все клиенты работают (затраты на переключения задачи малы по сравнению с затратами на выполнение полезного действия) эффект будет минимальный (если вообще будет).
Имхо, Node тут как спутниковый навигатор для авто: позволит создать оптимальный маршрут. Но если дороги загружены на 7+ баллов, то чуда конечно же не случится.
Никак не могу понять, по сути потоки в ОС это же тоже самое что эвентлуп, тока он реализован в 1 потоке и более высокоуровневый, почему тогда много«поточность» в нем дешевле чем системный.

Потому что LOOP это один поток… Когда процессор переключается на другой поток, он должен сделать переключение контекста… эТо дорогостоящая операция ,-он типа сохраняет все переменные в стек… делает ещё кучу всего… потом переключается на другой процесс(поток), восстанавливает его контекст. Делает дофига ненужного.(с точки зрения КПД)
Вот Википедия пишет про контекст процесса
А вот если один процесс хоть и в петле переключать контекст не нужно.

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