Comments 48
UFO just landed and posted this here
Лучше было бы собрать как минимум при помощи checkinstall
checkinstall --fstrans=no --install=no --pkgname=node.js --pkgversion «0.1.97» --default
+1
самый простой вариант — запускать screen, либо запускать с амперсандом в конце, выключая при помощи команды killall node.
Если запускать с ампресандом в конце — то при выходе из консоли он всеравно закроется. Есть такая команда nohup
А еще есть утилита start-stop-daemon
+4
под линуксом лучше таки собрать пакет и поставить его средствами пакетного менеджера. а не превращать систему в слаку. сборка пакета довольно проста. для deb-based дистрибутивов, например, можно использовать checkinstall. т.е.
make
sudo checkinstall -D make install
аналогично, его можно использовать для сборки rpm-пакета.
make
sudo checkinstall -D make install
аналогично, его можно использовать для сборки rpm-пакета.
0
+1
UFO just landed and posted this here
Один язык для клиента и сервера — это естественно ;)
+2
Во-первых, для серверных COMET решений преимущества для тех, кто никогда не использовал Ruby или Python — node очень прост в изучении, это знакомый javascript.
Во-вторых, скорость, она великолепна.
Во-вторых, скорость, она великолепна.
+1
Основных преимуществ два — скорость + память.
Основной недостаток — количество вспомогательных библиотек, молодость решения.
Более конкретно о преимуществах и недостатках можно говорить, в зависимости от того, с каким другим решением осуществляется сравнение.
Не последнюю роль здесь играют личные предпочтения разработчиков и уже существующий серверный фреймворк, если он есть.
Скажем, у меня CRM на django — так почему бы не взять Tornado/Twisted?
Или система на Java — естественное решение cometD / Jetty / Grizzly.
Можно везде использовать одну и ту же модель, это очень удобно.
Основной недостаток — количество вспомогательных библиотек, молодость решения.
Более конкретно о преимуществах и недостатках можно говорить, в зависимости от того, с каким другим решением осуществляется сравнение.
Не последнюю роль здесь играют личные предпочтения разработчиков и уже существующий серверный фреймворк, если он есть.
Скажем, у меня CRM на django — так почему бы не взять Tornado/Twisted?
Или система на Java — естественное решение cometD / Jetty / Grizzly.
Можно везде использовать одну и ту же модель, это очень удобно.
0
UFO just landed and posted this here
На FreeBSD чтобы не собирать libexecinfo из портов достаточно сделать:
pkg_add -r libexecinfo
0
Для пользователей windows (если у вас node.exe и server.js лежат в разных местах) команда для запуска из-под Cygwin версии будет:
относительные пути не понимает, windows пути с любыми слэшами тоже не понимает.
node.exe /cygdrive/буква_диска/путь/до/скрипта/server.js
относительные пути не понимает, windows пути с любыми слэшами тоже не понимает.
+1
UFO just landed and posted this here
Это специально для Вас: habrahabr.ru/blogs/webdev/95972/ :)
0
UFO just landed and posted this here
Есть концепция сообщений (Web Workers API).
0
UFO just landed and posted this here
Node.JS вообще-то очень далек от стабильной версии. ;)
Да, это master.
Да, это master.
0
Оно работает на многих production серверах. Ему можно доверять.
В любом случае, сервер node надёжнее аналогичного, написанного на php и сокетах.
В любом случае, сервер node надёжнее аналогичного, написанного на php и сокетах.
-1
А как насчет Nginx upstream backend?
Рано или поздно всеравно придется задуматься о масштабируемости
Рано или поздно всеравно придется задуматься о масштабируемости
0
UFO just landed and posted this here
Честно говоря, на ум ничего не приходит. Но всеравно непонятно зачем это нужно.
+1
UFO just landed and posted this here
Простейший вариант — мастер-скрипт, запускающий отдельные процессы, может элементарно общаться с ними, событийно и асинхронно.
Вот пример общения с командой ls
Вот пример общения с командой ls
Example of running ls -lh /usr, capturing stdout, stderr, and the exit code:
var sys = require('sys'),
spawn = require('child_process').spawn,
ls = spawn('ls', ['-lh', '/usr']);
ls.stdout.addListener('data', function (data) {
sys.print('stdout: ' + data);
});
ls.stderr.addListener('data', function (data) {
sys.print('stderr: ' + data);
});
ls.addListener('exit', function (code) {
sys.puts('child process exited with code ' + code);
});
0
Есть, если процессы свои.
+1
Асинхронная архитектура отлично справляется с теми задачами, для которых предусмотрено асинхронное решение на всех этапах процесса обработки. Таким образом решается задача concurrency.
Например, операция отсылки содержимого файла на уровне OS асинхронна, сетевые операции асинхронны. Основной поток просто перепоручает задачу дальше и переходит к следующему запросу. В результате — multiuser concurrency.
Это работает не всегда. Точнее, не работает там, где асинхронность на некотором звене отсутствует.
Как должно быть? Вася поручил Маше, она поручила Паше, Паша получил Даше, Даша сказала ок — сделаю позвоню. И затем в обратную сторону.
Если на каком-то звене проблема, например, Даша решила сделать «пряма щас» (синхронно) — то Паша ждет ответа Даши, Маша ждет ответа Паши. Все курят.
В случае с node.js (not only) это происходит, например, с MySQL, для которой нет открытого асинхронного API. В этом случае для concurrency используются потоки.
Это отлично работает до тех пор, пока 1 процессор справляется с нагрузкой основного процесса. В 95% приложений так оно и есть, все в порядке.
Multiple CPU concurrency в оставшихся 5% (цифра приблизительная), и решается запуском нескольких процессов. При этом архитектура принципиально меняется, т.к. разные процессы имеют раздельное адресное пространство.
Как правило, стараются все равно хранить всех подключенных юзеров в одном массиве одного процесса, а детали зависят от того, откуда вообще берется 100% загруз CPU.
Вот, вкратце, все детали concurrency для Node.JS и других решений подобного рода, включая EventMachine (Ruby), Tornado/Twisted (Python), POE (Perl) и т.п.
Например, операция отсылки содержимого файла на уровне OS асинхронна, сетевые операции асинхронны. Основной поток просто перепоручает задачу дальше и переходит к следующему запросу. В результате — multiuser concurrency.
Это работает не всегда. Точнее, не работает там, где асинхронность на некотором звене отсутствует.
Как должно быть? Вася поручил Маше, она поручила Паше, Паша получил Даше, Даша сказала ок — сделаю позвоню. И затем в обратную сторону.
Если на каком-то звене проблема, например, Даша решила сделать «пряма щас» (синхронно) — то Паша ждет ответа Даши, Маша ждет ответа Паши. Все курят.
В случае с node.js (not only) это происходит, например, с MySQL, для которой нет открытого асинхронного API. В этом случае для concurrency используются потоки.
Это отлично работает до тех пор, пока 1 процессор справляется с нагрузкой основного процесса. В 95% приложений так оно и есть, все в порядке.
Multiple CPU concurrency в оставшихся 5% (цифра приблизительная), и решается запуском нескольких процессов. При этом архитектура принципиально меняется, т.к. разные процессы имеют раздельное адресное пространство.
Как правило, стараются все равно хранить всех подключенных юзеров в одном массиве одного процесса, а детали зависят от того, откуда вообще берется 100% загруз CPU.
Вот, вкратце, все детали concurrency для Node.JS и других решений подобного рода, включая EventMachine (Ruby), Tornado/Twisted (Python), POE (Perl) и т.п.
0
Это хорошо. Статья полезная.
Но у меня сразу возник вопрос о перезапуске приложений. Тоесть допустим зарелизили версию приложения, она работает например как сервер для онлайн игры. Нужно в релизе поправить пару багофиксов или сменить игровой баланс настроить. Как тогда это делается? Есть ли какие-то средства он-аир изменений? Или стоп-старт в любом случае необходим.
Интересна именно потенциальная возможность. Понятно что в реальном проекте это делается балансировщиками и проксирующими серверами, но допустим их нету (архи-хреновая архитектура)
Но у меня сразу возник вопрос о перезапуске приложений. Тоесть допустим зарелизили версию приложения, она работает например как сервер для онлайн игры. Нужно в релизе поправить пару багофиксов или сменить игровой баланс настроить. Как тогда это делается? Есть ли какие-то средства он-аир изменений? Или стоп-старт в любом случае необходим.
Интересна именно потенциальная возможность. Понятно что в реальном проекте это делается балансировщиками и проксирующими серверами, но допустим их нету (архи-хреновая архитектура)
0
У вышеупомянутого kurokikaze есть статья: Горячая замена кода в node.js
А так — да, придется перезагружать (это быстро, доли секунды, но переменные сбрасываются).
Можно переписать под себя — есть замечательная конструкция script:
var sys = require('sys'),
localVar = 123,
usingscript, evaled,
script = process.binding('evals').script;
usingscript = script.runInThisContext('localVar = 1;',
'myfile.js');
sys.puts('localVar: ' + localVar + ', usingscript: ' +
usingscript);
В двух словах — объект script может брать откуда-нибудь код скрипта, eval-ить его в машинный код (прекомпилировать), и затем многократно запускать.
А так — да, придется перезагружать (это быстро, доли секунды, но переменные сбрасываются).
Можно переписать под себя — есть замечательная конструкция script:
var sys = require('sys'),
localVar = 123,
usingscript, evaled,
script = process.binding('evals').script;
usingscript = script.runInThisContext('localVar = 1;',
'myfile.js');
sys.puts('localVar: ' + localVar + ', usingscript: ' +
usingscript);
В двух словах — объект script может брать откуда-нибудь код скрипта, eval-ить его в машинный код (прекомпилировать), и затем многократно запускать.
+3
Есть несколько подходов для горячей замены.
К примеру, github.com/isaacs/node-supervisor
Можно просто перезапрашивать файлы и модули при необходимости, об этом много писали в рассылке nodejs.
Новые функции и классы заменят старые, для новых объектов.
К примеру, github.com/isaacs/node-supervisor
Можно просто перезапрашивать файлы и модули при необходимости, об этом много писали в рассылке nodejs.
Новые функции и классы заменят старые, для новых объектов.
+1
При сборке под FreeBSD 8.0_RELEASE amd64 с первого раза не собралось:
Помогла эта ссылка: http://code.google.com/p/v8/issues/detail?id=726.
Там все просто, в v8/src/platform-freebsd.cc добавляется между int OS::ActivationFrameAlignment() и const char* OS::LocalTimezone(double time) реализация недостающей функции:
Может кому поможет.
...obj/release/cpu-profiler.o(.text._ZN2v88internal23ProfilerEventsProcessor19FunctionCreateEventEPhS2_i+0x81): In function `v8::internal::ProfilerEventsProcessor::FunctionCreateEvent(unsigned char*, unsigned char*, int)':
: undefined reference to `v8::internal::OS::ReleaseStore(long volatile*, long)'
obj/release/cpu-profiler.o(.text._ZN2v88internal23ProfilerEventsProcessor15CodeCreateEventENS0_6Logger16LogEventsAndTagsEiPhj+0xa3): more undefined references to `v8::internal::OS::ReleaseStore(long volatile*, long)' follow
scons: *** [obj/release/mksnapshot] Error 1
scons: building terminated because of errors.
Waf: Leaving directory `/home/atercattus/node.js/node-v0.1.97/build'
Build failed: -> task failed (err #2):
{task: libv8.a SConstruct -> libv8.a}
*** Error code 1
Помогла эта ссылка: http://code.google.com/p/v8/issues/detail?id=726.
Там все просто, в v8/src/platform-freebsd.cc добавляется между int OS::ActivationFrameAlignment() и const char* OS::LocalTimezone(double time) реализация недостающей функции:
void OS::ReleaseStore(volatile AtomicWord* ptr, AtomicWord value) {
__asm__ __volatile__(""::: «memory»);
*ptr = value;
}
Может кому поможет.
+1
У меня так и не получилось запустить Node.js на Windows 7 по вашей инструкции. Вот тут нашёл более рабочий вариант www.lazycoder.com/weblog/2010/03/18/getting-started-with-node-js-on-windows/
0
Лично меня заинтересовал этот язык.
Попробую покопать в сторону сокетов, чтобы онлайн соединения между пользователями осуществлять.
Спасибо
Попробую покопать в сторону сокетов, чтобы онлайн соединения между пользователями осуществлять.
Спасибо
0
Вот так попробуйте.
0
Sign up to leave a comment.
Установка node.js на Linux, FreeBSD, Windows