Захоплення Node JS альтернативою багатопотоковому

142

Якщо я правильно розумію, Node JS не блокує ... тож замість того, щоб чекати відповіді з бази даних чи іншого процесу, вона перейшла на щось інше і перевіряє пізніше.

Також це одна різьба.

Чи все це означає, що даний процес Node JS може повноцінно та ефективно використовувати одне ядро центрального процесора, але він не буде використовувати жодне інше ядро на машині, як в, він ніколи не використовуватиме більше одного за один раз.

Звичайно, це означає, що інші процесори все ще можуть використовуватися іншими процесами для таких речей, як база даних SQL або інші навмисно відокремлені важкі підпрограми процесора, якщо вони є окремим процесом.

Також у випадку, якщо процес NS JS має нескінченну цикл або функцію тривалого запуску, цей процес більше не корисний, доки не припиняється (або вбивається весь процес) безкінечний цикл або тривала функція.

Чи все це правильно? Чи правильно я розумію?

multithreading node.js

— Брайан Поле
джерело

2

"Вузол" не є однопоточним. Тільки двигун JS / V8 працює в одну нитку. Libuv частина NodeJS є багатопотоковою. Дивіться, чи дійсно NodeJS односмуговий?

— RaelB

1

Підключаємо stackoverflow.com/q/17959663/632951

— Pacerier

87

Досить правильно, так. Сервер node.js має внутрішній пул потоків, щоб він міг виконувати операції блокування та повідомляти головний потік за допомогою зворотного дзвінка або події, коли все завершиться.

Отже, я думаю, що він обмежено використовувати інше ядро для пулу потоків, наприклад, якщо ви читаєте файлову систему, що не блокує, це, ймовірно, реалізується, повідомляючи потік з пулу потоків, щоб виконати зчитування та встановити зворотний виклик, коли це зроблено, що означає, що читання може відбуватися в іншому потоці / ядрі, тоді як основна програма node.js робить щось інше.

Але з точки зору node.js, це повністю однопоточна передача і не буде використовувати безпосередньо одне ядро.

— jcoder
джерело

2

Я все ще новачок у Node.js і ціную обговорення тут. Я просто хотів зазначити, що робити припущення, що неблокуючі дзвінки підкріплені потоками блокуючих потоків, ймовірно, не мудро (не те, що @jcoder запропонував архітувати код навколо цих припущень). У цьому випадку, навіть якщо IO обробляється в окремому потоці з блокуючим викликом, цей потік в основному буде чекати на IO так чи інакше, тому він не буде використовувати інші ядра / процесори. Вказуйте на міцність використовуваних інструментів і не переживайте надто детально про низькі рівні інформації (поки вони не стануть проблемою).

— wbyoung

тож ми можемо робити інші прози, використовуючи зворотний дзвінок, як код JavaScript на

— фронті

37

Так, я б сказав, що ваше розуміння цілком правильне. Ця стаття (в архіві ) досить добре пояснює обґрунтування цієї конструкції. Це, мабуть, найважливіший параграф:

Apache багатопотоковий: він породжує потік на запит (або процес, це залежить від конф). Ви можете бачити, як цей накладний об'єм пам’яті збільшує кількість одночасних з'єднань і потрібно більше потоків для обслуговування декількох одночасних клієнтів. Nginx і Node.js не є багатопотоковими, оскільки потоки та процеси несуть великі витрати на пам'ять. Вони однопоточні, але на основі подій. Це виключає накладні витрати, створені тисячами потоків / процесів, обробляючи безліч з'єднань в одному потоці.

— Майкл Боргвардт
джерело

Стаття помилкова. Незважаючи на те, що багатопотоковий mppm mpcs існує, він несумісний практично з усіма щоденними конфігураціями, що використовуються. Apache багатопроцесорний, і не багатопоточний дотепер, і буде, ймовірно, назавжди. Я вважаю це катастрофальним, маніпулювання власними значеннями термінології - це лише приємна спроба приховати проблему, а не вирішити її.

— петерх

1

@peterh Ви не маєте сенсу. Стаття є повністю коректною, стверджуючи, що апач є багатопроцесорним або багатопоточним, залежно від конфігурації. Випадок мультипроцесу ще гірший, що стосується обробки багатьох з'єднань, що є єдиною причиною, коли Apache згадується в першу чергу. Крім того, дуже часто використовуваний модуль PHP багатопотоково прочитаний самостійно. І нарешті, хоча я не фахівець з апашшю, моє враження від інших статей полягає в тому, що робочий MPM насправді дуже часто використовується.

— Майкл Боргвардт

@MichaelBorgwardt Так, апач може бути багатопоточним, а також багатопроцесорним, я цього не заперечував. Але php несумісний з багатопроцесорною конфігурацією, і якби ви був експертом з апаш-програм, ви б точно знали це. Модуль php, який часто використовується, не є багатопоточним. Ваша інформація неправдива. Я пропоную спробувати тестову конфігурацію, і ви побачите. Це фактична річ, неважливо дискутувати, спробуйте, і ви побачите.

— петерх

27

Навіть якщо це стара тема, я думав, що поділюсь ідеєю, як використовувати більше одного ядра в додатку Node.JS. Як згадував Нурай Алтин - JXcore може це зробити.

Простий приклад:

var method = function () {
    console.log("this is message from thread no", process.threadId);
};

jxcore.tasks.runOnThread(0, method);
jxcore.tasks.runOnThread(1, method);

// this is message from thread no 1
// this is message from thread no 0

За замовчуванням є два потоки (ви можете змінити це за допомогою jxcore.tasks.setThreadCount())

Звичайно, є набагато більше, що можна зробити із завданнями. Документи тут .

Мало статей на цю тему:

— infografnet
джерело

13

Оскільки це питання задавали майже 2 роки тому. Все стає іншим або є альтернативні підходи до багатопотокової проблеми на Node.JS

Згідно з наведеною нижче публікацією в блозі, використовуючи вхідне розширення 'завдання', деякі можуть безпосередньо скористатися іншими доступними ядрами.

http://oguzbastemur.blogspot.com/2013/12/multithread-nodejs.html

— Нурай Алтин
джерело

1

Node.js - це однопоточний додаток, але він може підтримувати паралельність за допомогою концепції подій та зворотних викликів. Ось відео Філіпа Робертса, яке пояснює, як працюють петлі подій у javascript.

Натисніть тут, щоб переглянути відео

(Замість WebAPI в Node.js є API C ++)

— Саурах Ленде
джерело

2

Це має бути коментар

— Чернів