> У любого решения есть недостатки. Какие вы видите недостатки вашего решения?
как минимум то, что нужно стартовать отдельный поток, прежде чем использовать Function.prototype.sync() и другие функции — это не всегда удобно
> Ваш «реальный» код требует рефакторинга, имхо. Тогда он будет более читабельный.
это специально сделано, пусть народ воззреет реалии :)
> При использовании Sync.Parallel — как различать результаты функции? Например, мне необходимо скачать данные из файла, получить данные из базы и подгрузить данные с удалённого сайта. Я пускаю их паралельно, они возвращаются неизвестно в каком порядке. Но мне нужны все три аргумента. Как определить, какой из аргументов к какому запросу относится?
// Ассоциативный вариант
var results = Sync.Parallel(function(callback){
someAsyncFunction(2, 2, callback('foo')); // assign the result to 'foo'
someAsyncFunction(5, 5, callback('bar')); // assign the result to 'bar'
});
console.log(results); // { foo: 4, bar: 10 }
// Future
// Запускаем someAsyncFunction, но не блокируем поток
var foo = someAsyncFunction.future(null, 2, 2);
var bar = someAsyncFunction.future(null, 5, 5);
// А вот теперь, дожидаемся значений от foo и bar
console.log(foo.value, bar.value); // 4 10 - ровно через секунду (не две)
> Мы объединили возможности традиционного индексирования “по словам” со знаниями о той предметной области, к которой относится информация.
а можно подробнее? вручную обучали?
Зависит от соотношения Network/Processor — если это 9/1 (как у меня), то будет раз в 10 быстрее (это для одного процесса).
Но самое главное — это память. Если грамотно написать (а в nodejs это не так легко), то процесс будет кушать не более 100 МБ. 4 ядра — 4 таких процесса. Опять же, зависит от логики самой программы. Если это краулер, тогда зависит от размера страниц и количества одновременной обработки — это можно регулировать.
> К сожалению один воркер в памяти сьедает до 20 мегабайт ОЗУ. 100 воркеров сьедают 2 гигабайта
Зачем Вам 100 воркеров? У меня максимум 30 воркетов на сервер, и то, это сделано ради повышения эффективности работы с блокирующим I/O в php, а вовсе не ради ресурсов. Мои воркеры гребут rss, 90% времени его работы занимает трансфер данных из внешних источников. Было бы весьма разумно реализовать это на nodejs, но на этом завязано слишком много бизнес-логики в среде php.
Система работает эластично — если нагрузка небольшая, запущено в среднем 5 воркеров.
> Справедливости ради надо сказать, воркеры в формате TCP едят не меньше
Чем воркеры «в формате TCP» принципиально отличаются от воркеров «в формате I/O»? И что побужтает их кушать меньше?
> Если не секрет, какое кол-во ОЗУ сьедает ваш PHP-воркер в среднем?
60 MB
Данный вопрос очень сильно связан с конкретной задачей, которую выполняют Ваши воркеры. Например, если это рэсайзинг изображений — php тут вообще не нужен.
Это не tcp, это простой std I/O. Работает замечательно, поскольку основной упор времени именно на выполнение задач, передача данных в моем случае — спички.
Помоему, tcp необходим только в том случае, когда нужно общение между разными серверами.
а такой селектор?
$(".favorites li.has-new > a > span").css('color', '#4D1E1E').css('font-weight', 'bold');
> Очень надеюсь, что в скором времени, с выкатом обновлений сервиса, такие ухищрения уже будут не нужны.
Ухищрения всегда будут нужны, поскольку невозможно сделать универсальное решение для всех. Именно по этому, будем работать над удобным API для разработчиков.
> какое-то небольшое приложение на Node.js, которое в асинхронном режиме запускает 1 из 20 приложений для обработку запроса, а вот оно уже в своей физической папке с всеми зависимостями лежит %)
Именно так. А вот сами приложения — это по сути модули, которым передается дальнейшее упревление запросом.
Но это в случае, если ваши приложения хоть в чем-то однотипные, конечно же.
Кое-что забыл:
Не знаю, как с MySQL, но с mongodb из nodejs работать не очень удобно. Даже суперский mongoose, и тот сделан вообще не очевидно, хотя вроде бы и был создан для того, чтобы облегчить работу с mongo.
Вот с redis, например, работать легко и приятно.
NodeJS еще очень сырой для реализации приложений со сложной бизнес-логикой. Его асинхронные преимущества не могут не радовать, но их, при этом, сложнее тестировать, т.е. любой кусок кода становится неоднозначным. Во время разработки нужно анализировать больше зависимостей, чем в том же линейном php.
В вашем случае, преимущество nodejs как раз не в риалтайме, а в ресурсах и персистентности. Вы ведь можете легко масштабировать ваши приложения по мере возрастания нагрузки. Например, все 20 приложений могут работать на одном nodejs инстансе (один другому не мешая), в последствии, количество nodejs процессов можно увеличивать, раскидывать по физическим серверам, повышая при этом производительность. И даже порты разные не нужны, ведь для этого есть хосты.
Однозначно — если ваши приложения имеют нетривиальную модель, с nodejs вам будет сложновато организовать удобную инфраструктуру… имхо, JS код вообще сложно организовать :) Но тут уже все зависит от ваших архитектурных талантов.
как минимум то, что нужно стартовать отдельный поток, прежде чем использовать Function.prototype.sync() и другие функции — это не всегда удобно
> Ваш «реальный» код требует рефакторинга, имхо. Тогда он будет более читабельный.
это специально сделано, пусть народ воззреет реалии :)
> При использовании Sync.Parallel — как различать результаты функции? Например, мне необходимо скачать данные из файла, получить данные из базы и подгрузить данные с удалённого сайта. Я пускаю их паралельно, они возвращаются неизвестно в каком порядке. Но мне нужны все три аргумента. Как определить, какой из аргументов к какому запросу относится?
а можно подробнее? вручную обучали?
["1","2","3"].map(Number)по-моему, круче
Но самое главное — это память. Если грамотно написать (а в nodejs это не так легко), то процесс будет кушать не более 100 МБ. 4 ядра — 4 таких процесса. Опять же, зависит от логики самой программы. Если это краулер, тогда зависит от размера страниц и количества одновременной обработки — это можно регулировать.
Это можно сделать на nodejs?
Зачем Вам 100 воркеров? У меня максимум 30 воркетов на сервер, и то, это сделано ради повышения эффективности работы с блокирующим I/O в php, а вовсе не ради ресурсов. Мои воркеры гребут rss, 90% времени его работы занимает трансфер данных из внешних источников. Было бы весьма разумно реализовать это на nodejs, но на этом завязано слишком много бизнес-логики в среде php.
Система работает эластично — если нагрузка небольшая, запущено в среднем 5 воркеров.
> Справедливости ради надо сказать, воркеры в формате TCP едят не меньше
Чем воркеры «в формате TCP» принципиально отличаются от воркеров «в формате I/O»? И что побужтает их кушать меньше?
> Если не секрет, какое кол-во ОЗУ сьедает ваш PHP-воркер в среднем?
60 MB
Данный вопрос очень сильно связан с конкретной задачей, которую выполняют Ваши воркеры. Например, если это рэсайзинг изображений — php тут вообще не нужен.
$this->_stdin = fopen('php://stdin', 'r+'); $this->_stdout = fopen('php://stdout', 'w+');Помоему, tcp необходим только в том случае, когда нужно общение между разными серверами.
while ($request = fgets($this->_stdin)) { $this->handleData($request); }Сами пользуемся — работает, как часы.
Пора апдейтить продакшн!
а такой селектор?
$(".favorites li.has-new > a > span").css('color', '#4D1E1E').css('font-weight', 'bold');
> Очень надеюсь, что в скором времени, с выкатом обновлений сервиса, такие ухищрения уже будут не нужны.
Ухищрения всегда будут нужны, поскольку невозможно сделать универсальное решение для всех. Именно по этому, будем работать над удобным API для разработчиков.
Именно так. А вот сами приложения — это по сути модули, которым передается дальнейшее упревление запросом.
Но это в случае, если ваши приложения хоть в чем-то однотипные, конечно же.
Не знаю, как с MySQL, но с mongodb из nodejs работать не очень удобно. Даже суперский mongoose, и тот сделан вообще не очевидно, хотя вроде бы и был создан для того, чтобы облегчить работу с mongo.
Вот с redis, например, работать легко и приятно.
В вашем случае, преимущество nodejs как раз не в риалтайме, а в ресурсах и персистентности. Вы ведь можете легко масштабировать ваши приложения по мере возрастания нагрузки. Например, все 20 приложений могут работать на одном nodejs инстансе (один другому не мешая), в последствии, количество nodejs процессов можно увеличивать, раскидывать по физическим серверам, повышая при этом производительность. И даже порты разные не нужны, ведь для этого есть хосты.
Однозначно — если ваши приложения имеют нетривиальную модель, с nodejs вам будет сложновато организовать удобную инфраструктуру… имхо, JS код вообще сложно организовать :) Но тут уже все зависит от ваших архитектурных талантов.
Главное — продукт. А все остальное — нюансы.