Comments 22
Лично мое мнение — нужно обождать с этими process.nextTick до появления воркеров. Особой выгоды пока не наблюдается.
Воркеры уже давно есть, node-webworker + пример :) В ядре их не предвидится.
1:0 в пользу nextTick() =)
По поводу вреда и частых запросов очень хочется заметить.
Так не бывает, node.js ставят в такие узкие места, где php уже не выдерживает, когда тысяча клиентов каждую секунду долбятся на сервер в поисках обновлений.
В таких случаях частые запросы — явление обязательное.
В том случае, когда запросы действительно редкие, мы можем хоть брейнфак с параметрами в процессе запускать для вычислений — это будет уже некритичным, теряется профит node.js.
По поводу вреда и частых запросов очень хочется заметить.
В случае, если запросы приходят редко, как в первом рассмотренном примере, вреда от process.nextTick() не будет совсем.
Так не бывает, node.js ставят в такие узкие места, где php уже не выдерживает, когда тысяча клиентов каждую секунду долбятся на сервер в поисках обновлений.
В таких случаях частые запросы — явление обязательное.
В том случае, когда запросы действительно редкие, мы можем хоть брейнфак с параметрами в процессе запускать для вычислений — это будет уже некритичным, теряется профит node.js.
Прошу поправить меня, если я гдето чтото не так или не полностью понял.
На счёт профита я бы не сказал. Есть же ещё code reuse и, для кого-то, привычность самого языка. Пожалуй единственное, почему на Node.js пока не написали CMS или что-то подобное — лень и большое количество уже написанных движков необходимость в нормальном хостинге.
Я над этим работаю: github.com/olegp/mcms
Ваши схемы смутно напомнили мне курс по микроконтроллерам в университете, а в частности схемы сигнализации и стробирования. Мне кажется, что всей этой вознёй с Node.js программисты загоняют себя в рамки, так же как и в случае программирования под микроконтроллеры.
В случае микроконтроллера это оправдано т.к. нужно запихнуть логику в небольшое физическое пространство, например в замок. В случае же девелопмента это экономия на спичках. Если ваше приложение масштабируемо, тогда зачем привлекать в него ещё одну технологию, чтобы не покупать второй сервер. Если же нет, то Node.js вас не спасёт.
Ну или спасёт, если переписать всё на нём, но это уже другая история :)
В случае микроконтроллера это оправдано т.к. нужно запихнуть логику в небольшое физическое пространство, например в замок. В случае же девелопмента это экономия на спичках. Если ваше приложение масштабируемо, тогда зачем привлекать в него ещё одну технологию, чтобы не покупать второй сервер. Если же нет, то Node.js вас не спасёт.
Ну или спасёт, если переписать всё на нём, но это уже другая история :)
У вас на первых картинках есть read(1) и read(2)… Я так понял это для случая когда для calc(1,2) нужны 2 файла? Просто на следующих картинках уже остается только один единственный read()
Что такое libeio Thread? Разве файлы читаются в потоке ОС? Вроде для файлов есть уже асинхронное АПИ на уровне ОС… Хотя это не сильно на суть влияет.
Было бы совсем круто если на каждом графике была бы подпись типа «readAsync()+nextTick()», «readAsync()», «readSync()» а то сейчас там где 2 графика склеено особенно долго вдумываться приходится.
Ну а по сути, в любом случае, вся производительность зависит от длины calc() отрезка, соответственно самый лучший способ ускорить NodeJS — сокращать этот отрезок как таковой для каждого запроса. Разбивать его на более мелкие — это работает до некоторого предела, пока у вас весь уровень EventLoop v8 не забьется calc() отрезками. А тогда уже нужно будет запускать воркеров и привет старый добрый апач…
Что такое libeio Thread? Разве файлы читаются в потоке ОС? Вроде для файлов есть уже асинхронное АПИ на уровне ОС… Хотя это не сильно на суть влияет.
Было бы совсем круто если на каждом графике была бы подпись типа «readAsync()+nextTick()», «readAsync()», «readSync()» а то сейчас там где 2 графика склеено особенно долго вдумываться приходится.
Ну а по сути, в любом случае, вся производительность зависит от длины calc() отрезка, соответственно самый лучший способ ускорить NodeJS — сокращать этот отрезок как таковой для каждого запроса. Разбивать его на более мелкие — это работает до некоторого предела, пока у вас весь уровень EventLoop v8 не забьется calc() отрезками. А тогда уже нужно будет запускать воркеров и привет старый добрый апач…
У вас на первых картинках есть 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() отрезками. А тогда уже нужно будет запускать воркеров и привет старый добрый апач…От этого никуда не удастся уйти. Никакой язык не позволит сделать то, что может лишний сервер :) Надеюсь это все понимают.
Так что в libeio асинхронность реализована своими силами.
Асинхронность файлового чтения или (OMG) сетевого сокета тоже? Надеюсь только первое…
Никакой язык не позволит сделать то, что может лишний серверНу тут просто можно упереться в одно ядро процессора а не в один сервер.
Прозрачного распределения по процессорам/ядрам у NodeJS, насколько я знаю, нет — просто запускают несколько «воркеров» и балансировщик нагрузки перед ними… Но тогда схема с NextTick еще менее ясной становится — если приходит новый клиент когда процесс Node занят calc-ом, то обработка будет поручена соседнему воркеру и необходимость в усложнении кода разбиением на nextTick отпадает.
Как бы это так высказать… Вот ось на графике «EventLoop v8» — это фактически «пропускная способность ядра процессора». Чтобы обрабатывать на сервере с NodeJS как можно больше клиентов, нужно максимально плотно расположить по этой линии все calc()-и (если узкое место — процессор, а не IO). И наиболее простой способ это сделать — запустить более чем одного воркера NodeJS на ядро процессора. В таком случае код усложнять не придется — приостанавливать выполнение calc() будет сама ОС прозрачно для программиста. Планировщик процессорного времени ОС (scheduler) так устроен, что он даст поработать одному процессу, притормозит его, даст поработать другому… Главный плюс — код программы не нужно усложнять без особой на то необходимости.
Асинхронность файлового чтения или (OMG) сетевого сокета тоже? Надеюсь только первое…Только первое, вторым заведует libev со стандартным набором select/poll/epoll/kqueue на выбор внутри.
Прозрачного распределения по процессорам/ядрам у NodeJS, насколько я знаю, нет — просто запускают несколько «воркеров» и балансировщик нагрузки перед ними… Но тогда схема с NextTick еще менее ясной становится — если приходит новый клиент когда процесс Node занят calc-ом, то обработка будет поручена соседнему воркеру и необходимость в усложнении кода разбиением на nextTick отпадает.Для этого как раз и сделан последний пример, из которого видно что польза от nextTick может быть, как раз таки за счёт плотного расположения. Ибо вне зависимости от количества воркеров это позволяет немного ускорить каждый из них в определённых ситуациях.
Надеюсь так стало лучше :)
Sign up to leave a comment.
Наглядно о потоке выполнения в Node.js