Так не бывает, node.js ставят в такие узкие места, где php уже не выдерживает, когда тысяча клиентов каждую секунду долбятся на сервер в поисках обновлений.
В таких случаях частые запросы — явление обязательное.
В том случае, когда запросы действительно редкие, мы можем хоть брейнфак с параметрами в процессе запускать для вычислений — это будет уже некритичным, теряется профит node.js.

ainu 1 фев 2011 в 20:40

Прошу поправить меня, если я гдето чтото не так или не полностью понял.

Sannis 1 фев 2011 в 20:43

Всё правильно поняли, кмк.

Sannis 1 фев 2011 в 20:43

На счёт профита я бы не сказал. Есть же ещё code reuse и, для кого-то, привычность самого языка. Пожалуй единственное, почему на Node.js пока не написали CMS или что-то подобное — ~~лень и большое количество уже написанных движков~~ необходимость в нормальном хостинге.

tyro 20 окт 2011 в 20:33

Я над этим работаю: github.com/olegp/mcms

Sannis 20 окт 2011 в 21:16

Как-то слишком просто :) Я замахивался на более крупное, но тут уже стольок других желающих набежанло (Nodeca, Calipso).

siasia 1 фев 2011 в 21:38

Ваши схемы смутно напомнили мне курс по микроконтроллерам в университете, а в частности схемы сигнализации и стробирования. Мне кажется, что всей этой вознёй с Node.js программисты загоняют себя в рамки, так же как и в случае программирования под микроконтроллеры.

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

Ну или спасёт, если переписать всё на нём, но это уже другая история :)

vgrichina 2 фев 2011 в 00:46

Node.js спасает в одном случае – много долгоиграющих соединений. Он для такого варианта использования очень хорош и удобен. Ну а для других вариантов – это больше just for fun, на яваскрипте покодить и все такое.

seriyPS 1 фев 2011 в 23:11

У вас на первых картинках есть read(1) и read(2)… Я так понял это для случая когда для calc(1,2) нужны 2 файла? Просто на следующих картинках уже остается только один единственный read()

Что такое libeio Thread? Разве файлы читаются в потоке ОС? Вроде для файлов есть уже асинхронное АПИ на уровне ОС… Хотя это не сильно на суть влияет.

Было бы совсем круто если на каждом графике была бы подпись типа «readAsync()+nextTick()», «readAsync()», «readSync()» а то сейчас там где 2 графика склеено особенно долго вдумываться приходится.

Ну а по сути, в любом случае, вся производительность зависит от длины calc() отрезка, соответственно самый лучший способ ускорить NodeJS — сокращать этот отрезок как таковой для каждого запроса. Разбивать его на более мелкие — это работает до некоторого предела, пока у вас весь уровень EventLoop v8 не забьется calc() отрезками. А тогда уже нужно будет запускать воркеров и привет старый добрый апач…

Sannis 1 фев 2011 в 23:34

У вас на первых картинках есть read(1) и read(2)… Я так понял это для случая когда для calc(1,2) нужны 2 файла? Просто на следующих картинках уже остается только один единственный read()

Да, всё верно. Имхо, это не суть важно, если суть понятна. В первом примере две операции чтения, необходимые для «расчётов», а далее изображена только одна. Я думал думал нарисовать пример с чтением двух файлов, независимо обработкой и последующей синхронизацией, но по остановился на приведённых примерах.

Что такое libeio Thread? Разве файлы читаются в потоке ОС? Вроде для файлов есть уже асинхронное АПИ на уровне ОС… Хотя это не сильно на суть влияет.

Да, в потоке OC. Во-первых, для переносимости. Во-вторых, судя по обсуждению в рассылке nodejs, в ядре 2.6 (или в glibc такого-же возраста) асинхронные операции также поддерживаются этим способом. Так что в libeio асинхронность реализована своими силами.

Было бы совсем круто если на каждом графике была бы подпись типа «readAsync()+nextTick()», «readAsync()», «readSync()» а то сейчас там где 2 графика склеено особенно долго вдумываться приходится.

Спасибо, стараюсь сделать хорошие иллюстрации, так что добавлю заголовки на них.

Ну а по сути, в любом случае, вся производительность зависит от длины calc() отрезка, соответственно самый лучший способ ускорить NodeJS — сокращать этот отрезок как таковой для каждого запроса. Разбивать его на более мелкие — это работает до некоторого предела, пока у вас весь уровень EventLoop v8 не забьется calc() отрезками. А тогда уже нужно будет запускать воркеров и привет старый добрый апач…

От этого никуда не удастся уйти. Никакой язык не позволит сделать то, что может лишний сервер :) Надеюсь это все понимают.

seriyPS 2 фев 2011 в 00:40

Так что в libeio асинхронность реализована своими силами.

Асинхронность файлового чтения или (OMG) сетевого сокета тоже? Надеюсь только первое…

Никакой язык не позволит сделать то, что может лишний сервер

Ну тут просто можно упереться в одно ядро процессора а не в один сервер.

Прозрачного распределения по процессорам/ядрам у NodeJS, насколько я знаю, нет — просто запускают несколько «воркеров» и балансировщик нагрузки перед ними… Но тогда схема с NextTick еще менее ясной становится — если приходит новый клиент когда процесс Node занят calc-ом, то обработка будет поручена соседнему воркеру и необходимость в усложнении кода разбиением на nextTick отпадает.

Как бы это так высказать… Вот ось на графике «EventLoop v8» — это фактически «пропускная способность ядра процессора». Чтобы обрабатывать на сервере с NodeJS как можно больше клиентов, нужно максимально плотно расположить по этой линии все calc()-и (если узкое место — процессор, а не IO). И наиболее простой способ это сделать — запустить более чем одного воркера NodeJS на ядро процессора. В таком случае код усложнять не придется — приостанавливать выполнение calc() будет сама ОС прозрачно для программиста. Планировщик процессорного времени ОС (scheduler) так устроен, что он даст поработать одному процессу, притормозит его, даст поработать другому… Главный плюс — код программы не нужно усложнять без особой на то необходимости.

Sannis 2 фев 2011 в 06:59

Асинхронность файлового чтения или (OMG) сетевого сокета тоже? Надеюсь только первое…

Только первое, вторым заведует libev со стандартным набором select/poll/epoll/kqueue на выбор внутри.

Прозрачного распределения по процессорам/ядрам у NodeJS, насколько я знаю, нет — просто запускают несколько «воркеров» и балансировщик нагрузки перед ними… Но тогда схема с NextTick еще менее ясной становится — если приходит новый клиент когда процесс Node занят calc-ом, то обработка будет поручена соседнему воркеру и необходимость в усложнении кода разбиением на nextTick отпадает.

Для этого как раз и сделан последний пример, из которого видно что польза от nextTick может быть, как раз таки за счёт плотного расположения. Ибо вне зависимости от количества воркеров это позволяет немного ускорить каждый из них в определённых ситуациях.

Sannis 2 фев 2011 в 11:30

Надеюсь так стало лучше :)

seriyPS 2 фев 2011 в 11:53

Ага, спасибо!

Зарегистрируйтесь на Хабре, чтобы оставить комментарий