Comments 36
Сначала подумал что принципиально отличий от pm2 index.js --instances=0 (все ядра) нет, но сразу понял, что отличие в том, что pm2 кластеризует один и тот же index.js. Можно конечно пытаться разруливать внутри кода, но это бредово выходит при наличии подхода с акторами и comedy.
Обычно я использую loopback для rest-сервисов (так как он имеет работу с источниками данных уже сразу), и следующие проекты делать на нем планирую так или иначе. И даже в этом случае акторы полезны для серверного кода, который бы хотелось вынести в отдельный процесс.
Пока неясно, насколько это всё дружит с pm2. Навскидку, раз comedy разбивает по ядрам сам, достаточно родительский сервис запустить с --instances=N, где N > 0.
Поскольку pm2 будет размножать корневой ("пусковой") процесс — а система акторов у вас создаётся, по-идее, именно там — то у нас получится несколько систем акторов, по одной на каждый корневой процесс. Никаких проблем с этим нет, если вас устраивает, что вместо одного дерева акторов у вас всегда будет лес из N деревьев.
В ситуации с типипичными задачами web-serving лес в большинстве случаев действительно не проблема.
Хорошо, когда можно просто взять — и размножить приложение на N экземпляров. Это простой случай.
В случае же с нашим проектом акторы стали реальным спасением, поскольку в SAYMON HTTP-шный веб-сервер — это лишь один из большого множества модулей, слушающих информацию из сети либо обрабатывающих её в фоновом режиме. У нас есть Comet-сервер, обработчик MQTT-сообщений, обработчик SNMP-трапов, обработчик сообщений, приходящих по publish-subscribe от агентов, отправители E-mail и Telegram уведомлений, верификатор состояния модели и прочее. Размножить всё это на N экземпляров — отдельная большая фича, требующая серьёзных трудозатрат. А акторы позволяют более гранулярно отмаштабировать "горячие" модули и оставить в одном экземпляре то, что мы пока не хотим или не можем масштабировать.
В случае с loopback (он кстати тоже умеет socket.io) и акторами жизнь такая мне видится:
1. pm2 работает со стандартным loopback-сервером, и кластеризует по заданному явно количеству ядер, и не является актором,
2. и уже на каждый запрос, который требует процесса (а они далеко не все такие) — создается актор.
Это вполне удобно, так как данные туда-сюда внутри кода, в отличие от явного запуска процессов и прочего IPC с перекладными конструкциями в коде.
Что на счет дебага такого подхода? Есть подводные камни?
Для дебага есть такие возможности:
- можно дебажить отдельный актор изолированно при запуске его unit-тестов
- можно дебажить систему целиком в in-memory режиме (для этого в параметрах системы акторов есть специальная булевская опция
debug; она форсит in-memory режим для всех акторов, включает длинные стектрейсы в bluebird и выставляет уровень логирования в debug)
Полноценно дебажить систему с forked или remote акторами с подключением дебаггера не получится. Здесь вам в помощь только логгер и console.log. Возможно, в дальнейшем удастся добавить интроспекцию.
Реквестирую сравнение с конкурентами.
В момент, когда я начинал разрабатывать Comedy, в Node.JS мире на тему акторов я нашёл только маленький экспериментальный фреймворк под названием Drama (собственно, он меня и вдохновил). Сейчас ещё нашёл nactor. В первом даже есть forked режим, который работает в самом простейшем случае (во втором, кажется, нет и этого). Ни в одном из этих ферймворков нет механизма внешнего конфигурирования акторов (только через код), не говоря уж о кластеризации, remote-режиме, поддержки инъекции ресурсов, кастомном маршаллинге, fault tolerance — проще перечислить, что в них есть, чем чего в них нет.
Если сравнивать с фреймфорками в других языках (c AKKA, например), то это, в принципе, отдельная статья :)
Как ни странно, Comedy не гуглится по запросу "actors nodejs". Печалька :(
Если найдёте какие-то другие фреймворки для акторов в Node.JS — пишите обязательно!
Оверхед станет понятен как только:
- Будет написан бенчмарк на JSON сериализацию.
- Будет набросок альтернативной сериализации.
- Будет бенчмарк по альтернативной сериализации.
Пока что есть только бенчмарки на коммуникацию между акторами, туда входит сериализация и обмен через IPC или loopback socket. Но сравнивать результаты пока не с чем. Думаю, в течение плутора-двух месяцев можно будет потестировать различные варианты сериализации и выбрать лучший + выставить опцию для конфигурирования пользовательской сериализации.
Если найдёте какие-то другие фреймворки для акторов в Node.JS — пишите обязательно!
https://github.com/liangzeng/cqrs
https://github.com/tarantx/tarant
eval() — это не единственный и не самый рекомендованный способ передачи определения актора. Можно предварительно разместить код проекта на удалённой машине и в качестве определения актора указывать путь к файлу (это как раз то, что рекомендуется). В этом случае, код определения будет подтянут через стандартный require().
comedy-node — это очень тупой процесс, который вообще ничего и никогда не знает про акторы. Всё, что он делает — слушает порт, по которому принимает запросы на создание актора. При каждом таком запросе он запускает подпроцесс, который как раз ответственен за создание актора и управление его жизненным циклом. Этот процесс от comedy-node полностью независим. Он слушает свой собственный порт и переживает смерть comedy-node.
Привет. Я правильно понимаю, что это всё же параллелизм на уровне процессов, и по-прежнему в кластере из четырех акторов можно добиться не более 4-х реально одновременно выполняющихся CPU-bound задач?
П.С. а почему таки не подпилили под интерфейс web workers?
Привет!
в кластере из четырех акторов можно добиться не более 4-х реально одновременно выполняющихся CPU-bound задач
Да, всё верно.
а почему таки не подпилили под интерфейс web workers?
Честно говоря, с Web-воркерами мало работал и мало про них знаю. Вижу что они, похоже, есть в Node.JS (https://www.npmjs.com/package/webworker-threads). Значит, можно сделать ещё один режим для акторов, в котором они запускаются в веб-воркерах!
По интерфейсу я, скорее, ориентировался на AKKA, поскольку это стандарт де-факто в мире акторов (уж не знаю, насколько они с Comedy в итоге похожи :) ). Во всяком случае, хотелось иметь максимально ООП-шный интерфейс, при котором ваши существующие классы легко превращаются в элегантные акторы.
Вот запуски с ними и без команды pm2 start index.js -i 4.
var Worker = require('webworker-threads').Worker;
require('http').createServer(function (req,res) {
var fibo = new Worker(function() {
function fibo (n) {
return n > 1 ? fibo(n - 1) + fibo(n - 2) : 1;
}
this.onmessage = function (event) {
postMessage(fibo(event.data));
}
});
fibo.onmessage = function (event) {
res.end('fib(40) = ' + event.data);
};
fibo.postMessage(40);
}).listen(8080);
$ loadtest -n 100 -c 20 http://localhost:8080
[Tue Aug 15 2017 11:25:36 GMT+0700 (Томск (зима))] INFO Requests: 0 (0%), requests per second: 0, mean latency: 0 ms
[Tue Aug 15 2017 11:25:41 GMT+0700 (Томск (зима))] INFO Requests: 0 (0%), requests per second: 0, mean latency: 0 ms
[Tue Aug 15 2017 11:25:46 GMT+0700 (Томск (зима))] INFO Requests: 20 (20%), requests per second: 6, mean latency: 7684.4 ms
[Tue Aug 15 2017 11:25:51 GMT+0700 (Томск (зима))] INFO Requests: 20 (20%), requests per second: 0, mean latency: 0 ms
[Tue Aug 15 2017 11:25:56 GMT+0700 (Томск (зима))] INFO Requests: 40 (40%), requests per second: 5, mean latency: 7978.3 ms
[Tue Aug 15 2017 11:26:01 GMT+0700 (Томск (зима))] INFO Requests: 60 (60%), requests per second: 6, mean latency: 7794.4 ms
[Tue Aug 15 2017 11:26:06 GMT+0700 (Томск (зима))] INFO Requests: 60 (60%), requests per second: 0, mean latency: 0 ms
[Tue Aug 15 2017 11:26:11 GMT+0700 (Томск (зима))] INFO Requests: 80 (80%), requests per second: 5, mean latency: 7911.8 ms
[Tue Aug 15 2017 11:26:16 GMT+0700 (Томск (зима))] INFO Requests: 96 (96%), requests per second: 4, mean latency: 7667 ms
[Tue Aug 15 2017 11:26:17 GMT+0700 (Томск (зима))] INFO
[Tue Aug 15 2017 11:26:18 GMT+0700 (Томск (зима))] INFO Target URL: http://localhost:8080
[Tue Aug 15 2017 11:26:19 GMT+0700 (Томск (зима))] INFO Max requests: 100
[Tue Aug 15 2017 11:26:20 GMT+0700 (Томск (зима))] INFO Concurrency level: 20
[Tue Aug 15 2017 11:26:21 GMT+0700 (Томск (зима))] INFO Agent: none
[Tue Aug 15 2017 11:26:22 GMT+0700 (Томск (зима))] INFO
[Tue Aug 15 2017 11:26:22 GMT+0700 (Томск (зима))] INFO Completed requests: 100
[Tue Aug 15 2017 11:26:22 GMT+0700 (Томск (зима))] INFO Total errors: 0
[Tue Aug 15 2017 11:26:22 GMT+0700 (Томск (зима))] INFO Total time: 41.200597607000006 s
[Tue Aug 15 2017 11:26:22 GMT+0700 (Томск (зима))] INFO Requests per second: 2
[Tue Aug 15 2017 11:26:22 GMT+0700 (Томск (зима))] INFO Mean latency: 7891 ms
[Tue Aug 15 2017 11:26:22 GMT+0700 (Томск (зима))] INFO
[Tue Aug 15 2017 11:26:22 GMT+0700 (Томск (зима))] INFO Percentage of the requests served within a certain time
[Tue Aug 15 2017 11:26:22 GMT+0700 (Томск (зима))] INFO 50% 7809 ms
[Tue Aug 15 2017 11:26:22 GMT+0700 (Томск (зима))] INFO 90% 8312 ms
[Tue Aug 15 2017 11:26:22 GMT+0700 (Томск (зима))] INFO 95% 8763 ms
[Tue Aug 15 2017 11:26:22 GMT+0700 (Томск (зима))] INFO 99% 9857 ms
[Tue Aug 15 2017 11:26:22 GMT+0700 (Томск (зима))] INFO 100% 9857 ms (longest request)
function fibo(n) {
return n > 1 ? fibo(n - 1) + fibo(n - 2) : 1;
}
require('http').createServer(function (req,res) {
res.end('fib(40) = ' + fibo(40));
}).listen(8080);
$ loadtest -n 100 -c 20 http://localhost:8080
[Tue Aug 15 2017 11:23:25 GMT+0700 (Томск (зима))] INFO Requests: 0 (0%), requests per second: 0, mean latency: 0 ms
[Tue Aug 15 2017 11:23:30 GMT+0700 (Томск (зима))] INFO Requests: 11 (11%), requests per second: 2, mean latency: 3095.5 ms
[Tue Aug 15 2017 11:23:35 GMT+0700 (Томск (зима))] INFO Requests: 20 (20%), requests per second: 2, mean latency: 6402.4 ms
[Tue Aug 15 2017 11:23:40 GMT+0700 (Томск (зима))] INFO Requests: 35 (35%), requests per second: 3, mean latency: 8022.7 ms
[Tue Aug 15 2017 11:23:45 GMT+0700 (Томск (зима))] INFO Requests: 47 (47%), requests per second: 2, mean latency: 9373.1 ms
[Tue Aug 15 2017 11:23:50 GMT+0700 (Томск (зима))] INFO Requests: 59 (59%), requests per second: 2, mean latency: 8102.9 ms
[Tue Aug 15 2017 11:23:55 GMT+0700 (Томск (зима))] INFO Requests: 71 (71%), requests per second: 2, mean latency: 8110.2 ms
[Tue Aug 15 2017 11:24:00 GMT+0700 (Томск (зима))] INFO Requests: 83 (83%), requests per second: 2, mean latency: 8085.8 ms
[Tue Aug 15 2017 11:24:05 GMT+0700 (Томск (зима))] INFO Requests: 95 (95%), requests per second: 2, mean latency: 8277.5 ms
[Tue Aug 15 2017 11:24:07 GMT+0700 (Томск (зима))] INFO
[Tue Aug 15 2017 11:24:07 GMT+0700 (Томск (зима))] INFO Target URL: http://localhost:8080
[Tue Aug 15 2017 11:24:07 GMT+0700 (Томск (зима))] INFO Max requests: 100
[Tue Aug 15 2017 11:24:07 GMT+0700 (Томск (зима))] INFO Concurrency level: 20
[Tue Aug 15 2017 11:24:07 GMT+0700 (Томск (зима))] INFO Agent: none
[Tue Aug 15 2017 11:24:07 GMT+0700 (Томск (зима))] INFO
[Tue Aug 15 2017 11:24:07 GMT+0700 (Томск (зима))] INFO Completed requests: 100
[Tue Aug 15 2017 11:24:07 GMT+0700 (Томск (зима))] INFO Total errors: 0
[Tue Aug 15 2017 11:24:07 GMT+0700 (Томск (зима))] INFO Total time: 42.051199002000004 s
[Tue Aug 15 2017 11:24:07 GMT+0700 (Томск (зима))] INFO Requests per second: 2
[Tue Aug 15 2017 11:24:07 GMT+0700 (Томск (зима))] INFO Mean latency: 7566.9 ms
[Tue Aug 15 2017 11:24:07 GMT+0700 (Томск (зима))] INFO
[Tue Aug 15 2017 11:24:07 GMT+0700 (Томск (зима))] INFO Percentage of the requests served within a certain time
[Tue Aug 15 2017 11:24:07 GMT+0700 (Томск (зима))] INFO 50% 7968 ms
[Tue Aug 15 2017 11:24:07 GMT+0700 (Томск (зима))] INFO 90% 8691 ms
[Tue Aug 15 2017 11:24:07 GMT+0700 (Томск (зима))] INFO 95% 10576 ms
[Tue Aug 15 2017 11:24:07 GMT+0700 (Томск (зима))] INFO 99% 17433 ms
[Tue Aug 15 2017 11:24:07 GMT+0700 (Томск (зима))] INFO 100% 17433 ms (longest request)
Вобщем с ними в два раза быстрее получилось… хотя второй вариант откровенно глуповат, но это для иллюстрации.
Крутяк! Будем реализовывать!
165580141
/c/OpenServer/modules/php/PHP-5.6/php
$ timeout 60s php index.php
$ cat index.php
<?php
function fibo($n) {
return $n > 1? (fibo($n — 1) + fibo($n — 2)): 1;
}
print 'fib(40) = '. fibo(40);
?>
Машина 4 ядра Intel Core i5-3330 3.00 GHz 8Gb Win10x64
$ node --version
v8.4.0
$ php --version
PHP 7.1.8 (cli) (built: Aug 1 2017 21:10:31) ( NTS MSVC14 (Visual C++ 2015) x86 )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2017 Zend Technologies
$ cat index.js
function fibo(n) {
return n > 1 ? (fibo(n - 1) + fibo(n - 2)) : 1;
};
console.log('fib(40) = ' + fibo(40));
$ cat index.php
<?php
function fibo($n) {
return $n > 1 ? (fibo($n - 1) + fibo($n - 2)) : 1;
}
print 'fib(40) = ' . fibo(40);
?>
$ ptime node .
ptime 1.0 for Win32, Freeware - http://www.pc-tools.net/
Copyright(C) 2002, Jem Berkes <jberkes@pc-tools.net>
=== node . ===
fib(40) = 165580141
Execution time: 2.164 s
$ ptime php index.php
ptime 1.0 for Win32, Freeware - http://www.pc-tools.net/
Copyright(C) 2002, Jem Berkes <jberkes@pc-tools.net>
=== php index.php ===
fib(40) = 165580141
Execution time: 22.862 s
$ ptime node plain.js
ptime 1.0 for Win32, Freeware - http://www.pc-tools.net/
Copyright(C) 2002, Jem Berkes <jberkes@pc-tools.net>
=== node plain.js ===
fib(40) = 165580141
Execution time: 0.626 s
$ ptime.exe php plain.php
ptime 1.0 for Win32, Freeware - http://www.pc-tools.net/
Copyright(C) 2002, Jem Berkes <jberkes@pc-tools.net>
=== php plain.php ===
fib(40) = 165580141
Execution time: 0.083 s
$ cat plain.js
function fibo(n) {
let x = 1, y = 1, result;
for (let i = 1; i < n; ++i) {
result = x + y;
x = y;
y = result;
}
return result;
}
console.log('fib(40) = ' + fibo(40));
$ cat plain.php
<?php
function fibo($n) {
$x = 1; $y = 1; $result;
for ($i = 1; $i < $n; ++$i) {
$result = $x + $y;
$x = $y;
$y = $result;
}
return $result;
}
echo 'fib(40) = ' . fibo(40);
?>Заметьте, разница в 10 раз с рекурсией в пользу node, и в 10 раз без рекурсии в пользу php. Пока могу объяснить только тем, что при рекурсии node не копирует scope, а при прямом проходе php у php7.1 весьма эффективный байткод (5.6 при первом проходе показал 0.424, при втором ~0.150). Косвенно это подтверждается тем, что если в plain.js/php добавить второй вызов fibo(40), у ноды время исполнения увеличивается на 0.011, у php вообще уменьшается на 0.003 :) — вобщем на уровне погрешности измерения и там и там.
TL;DR: похоже node долго компилит, работает быстро, php быстро компилит, быстро на примитивных операциях, но плохо работает с памятью.
Но рекурсия не тот бенчмарк, который релевантен множеству типичных задач. Просто делюсь небольшим для себя откровением.
Когда мы только начинали проект SAYMON, Erlang был одной из технологий, которую я рассматривал для бэкенда. Я с ним обязательно познакомлюсь по мере возможности.
По сравнению с другими платформами у Node.JS есть одно, на первый взгляд незаметное, преимущество: вы можете частично переиспользовать фронтэндеров для бэкенд задач. Часто бывает так, что для реализации задачи нужно сделать большой кусок UI и небольшой кусочек сервера (например, добавить простенький REST-метод). Когда этим занимается один и тот же человек, это происходит гораздо быстрее. В маленьких стартапчиках, как наш, это очень спасает.
Пожалуйста! Пожалуйста, перестаньте называть обработчики запросов "ручками". Не знаю, от какого двоечника это пошло, и почему остальные это повторяют — но "handle" и "handler" это абсолютно разные вещи, они даже пишутся по разному! И ладно бы это облегчало понимание — так нет, бессмысленный сленг ради сленга. Слышал словосочетание "звонить в ручку" — пожалуйста, прекратите это!
А теперь по делу — куча лишних понятий и кода, когда то же самое делается node cluster или pm2. И там и там выносите в отдельное приложение свой rest сервер и вуаля. И не надо никаких велосипедных экторов и балансировщиков (делать свой балансировщик при том, что практически у всех нода находится под nginx — это ужасно).
Ну и вообще. Я понимаю, что пример искусственный, но такие вещи решаются созданием очередей, генераторами или приведением кода с асинхронному виду. А единственное, чего достигли вы — это загрузить все ядра.
Я на эту тему уже давал комментарий здесь. В нашем случае REST и Nginx — это лишь малая часть нашего приложения.
node-cluster — слишком низкоуровневое API, нам удобнее работать с ООП. Плюс не вынести на удалённые машины. Плюс нет из коробки внешней конфигурации. Плюс самому пилить respawn, если форкнутый процесс отвалился.
Насчёт приведения кода к асинхронному виду — в случае CPU-intensive задач вам это не поможет. В реальных проектах, таких как SAYMON, весь код вдрызг асинхронный, но процессорное время ему нужно так или иначе.
Перевести наш проект полностью на очереди на самом деле было бы более трудоёмко, чем внедрить акторы. Кстати, очереди сообщений могли бы служить низлежащим транспортом для обмена сообщений между акторами. Такая мысль была, и запросы есть, но реализовать пока не успели.
Пожалуйста, перестаньте называть обработчики запросов "ручками".
Я-то могу перестать (я просто в скобочках написал), но боюсь, что жаргон уже устоялся. Вы вряд ли сможете его изменить. Нужно принять и простить :)
Для балансировки чего попало можно использовать, например, haproxy, еслт вам nginx не хватает. А если вы не можете выделить "горячие точки" без серьёзных трудозатрат, то вероятно у вас проблемы с модульностью кода.
А что там низкоуровневого в node-cluster? Полторы функции, под которые можно сделать любую обёртку.
Код в асинхронному виде или с генераторами — перестанет вешать полностью event loop. Понятно, конечно, что задача от этого быстрее выполняться не станет.
Насчёт очередей — да, немного сложнее. Но жизнь становится гораздо лучше, когда есть шина для коммуникаций и сервисы обрабатывают ровно столько, сколько могут. К примеру, запускается два экземпляра на два ядра, а не пять. После этого можно спокойно выкидывать кучу логики балансера и фэйловера. Профит!
Насчёт "ручек" — не, не могу понять и простить. Видел это у одного кандидата на собеседовании и в четырех статьях на хабре. Так что жаргон не устоялся, и надеюсь, что не устроится. Интересно было бы найти первоисточник — подозреваю, какой-нибудь жуткий перевод статьи про Express.
Но почему такое название? Оно крайне слабо коррелирует с системой акторов.
С одной стороны, это хорошо, поскольку избавляет нас от целого класса очень стрёмных и трудновоспроизводимых багов — многопоточных багов. В наших приложениях таких багов быть принципиально не может, и это сильно удешевляет и ускоряет разработку.Это классическое заблуждение. Переход от многопоточной системы к однопоточному event-loop не решает проблем, а лишь переводит их в другую плоскость.
Вместо паттернов многопоточности теперь нужны паттерны для event-based подхода. Вместо гонки потоков, теперь есть гонка промисов/ивентов/воркеров, которые все так же нужно синхронизировать.
Это не ускоряет и тем более не удешевляет скорость разработки.
Но почему такое название?
По аналогии с фреймворком Drama, которым был вдохновлён Comedy. Ну, актёры, театр, драма, комедия...
Это классическое заблуждение. Переход от многопоточной системы к однопоточному event-loop не решает проблем, а лишь переводит их в другую плоскость.
Я с этим не согласен. В многопоточных системах есть и гонки потоков, и гонки ивентов/промисов. То есть, там есть и баги, связанные с многопоточностью, и баги, связанные с асинхронностью. В Node.JS мы имеем только баги второй разновидности. У нас нет проблем с visibility, например — когда мы ошибочно полагаем, что модификация переменной x видна и потоку A, и потоку B. У нас нет deadlock-ов. Их не может быть принципиально.
Я много занимался многопоточным программированием на Java и на C++. По моему опыту, скорость разработки на Node.JS в 2-4 раза выше, чем на Java, а с C++ я даже сравнивать боюсь.
Один раз нашел багу, но эта бага была из-за того, что кто-то захотел распараллелить обработку HTTP запроса. Но это человек умышленно решил выстрелить себе в ногу.
Да, с видимостью проблем нету в ноде, а с дедлоком в целом можно устроить, если запускать форки.
А вот на NodeJs совсем недавно я лечил багу связанную с лайвлоком, Jest + setTimeout не подружились и приложение зависло на CI сервере, учитывая, что на локальной машине оно отрабатывало отлично.
Так что, выстрелить себе в ногу можно на любой платформе, было бы желание, везение и/или предрасположенность.
Comedy. Акторы в Node.JS для гибкого масштабирования