Как стать автором
Обновить

Комментарии 72

Мне кажется, что как-то много приложений для установки окружения. Зачем это там IIS ставить, Zoo какой-то… мне кажется в конце концов вы получаете ненужный Zooпарк приложений, не относящихся к разработке на nodejs. В конце концов, вам все равно надо будет еще cygwin ставить, чтобы питон запускать. Т.е. все эти крендебобили с Microsoft продуктами вообще не нужны.
cool story, bro.
Спасибо, я прошелся по ссылке и сделал вывод, что это имеет смысл для production окружения, что очевидно. В статье, однако речь идет об окружении разработчика и в этом случае заниматься поднятием IIS сервера, имхо, является неким overhead'ом снижающим скорость разработки, когда голого nodejs достатчно ввиду поддержки IDE, например в Idea.

Зачем он нужен на дев машине?
Хмм… А я, дурак node.exe server.js запускал. И nginx.
В качестве Mysql-модуля используется библиотека от хабрапользователя Sannis, которую надо собирать или медленная (но нативная) github.com/felixge/node-mysql?
Зачем же так? Мы поддержку Node.js только месяц как сделали, вы не могли об этом знать.
Использовали нативный node-mysql. Мы все же не базу данных меряли, а просто хотели «утяжелить» запрос, чтобы показать как меняется график.
Ну я node.exe (без установки в систему цугвина) ещё год назад запускал. Потому и так, и как то не видел с этим проблем, сейчас вот прикидываю плюсы Web Platform Installer.
Плюс в том что это продакшн решение на IIS. Если вы будете разворачивать его потом на Windows сервере, то это самый прямой путь. Ну и плюс что все в одном месте ставится за пару кликов — не нужно бегать по ссылкам и собирать пакеты.
WebMatrix это продакшн решение?
В статье есть глава «Развертывание на сервере».

Неужели вы думаете мы на WebMatrix-е обогнали Linux сервер во всех тестах?
Про установку модулей в обход npm не знал. Надо попробовать поставить пакеты проверки скриптов и запуска юнит-тестов и прикрутить их к maven'у. Не совсем традиционное использование Нода, но для нас было бы очень кстати.
Отличная статья, спасибо!
Теперь становится понятным зачем нужен продукт WebMatrix профессионалам.
НЛО прилетело и опубликовало эту надпись здесь
Нет. Мы не работаем на Microsoft и даже никак с ними не связаны. В каком-то смысле мы даже конкурируем с ними, причем делаем это на их платформе, так что надежд мало…

Мы выпускаем продукты чтобы удовлетворить существующую потребность. Так уж вышло что продукты эти серверные. И выпускаем мы их на той платформе где есть спрос и где у нас есть опыт.

Microsoft часто выпускает затем аналогичные продукты. Взять например iisnode, который вышел после Helicon Zoo и значительно уступает ему, но о нем уже масса статей. Ну некому у нас статьи писать.

Или когда Microsoft встроила URL Rewrite Module в 2008 сервер, полностью вытеснив наш ISAPI_Rewrite с рынка.

О нашем Ape я могу долго рассказывать. Этот продукт в разы превосходит URL Rewrite module и ARR вместе взятые как по производительности так и по возможностям, но так и не стал популярным, потому что затем появились вышеназванные встроенные аналоги. А папуляризовать наше решение некому.

Так что не торопитесь ставить минус «поборникам корпорации зла» — правда как всегда где-то посредине.
НЛО прилетело и опубликовало эту надпись здесь
iisnode популярен и будет популярен потому, что разработчику, который хочет использовать node на Windows, нужно только то, что ему нужно. Ему не нужен ещё один пакетный менеджер. Ваше решение, судя по внешнему виду, подходит болше какому-нибудь хостинг-провайдеру, чем рядовому разработчику. А вы его хотите протолкнуть разработчикам.
Согласен, кто предпочитает все ставить руками, тому «еще один» пакетный менеджер не нужен.
Как метко подметили выше, iisnode кстати тоже не нужен — node.exe работает и без хитроумных менеджеров процессов, балансировщиков и веб серверов.
Крайне полезной фичей для хостинга NodeJS является IISNode — дополнение для IIS, позволяющее не «светить» открытый порт в мир (то есть порты IIS и NodeJS будут для клиентского браузера идентичными, работает через именованые пайпы, по заверениям автора — не блокирует собственную очередь IIS-соединений).

Умеет запускать по потоку на ядро процессора (конфигурируемо), перезагружать NodeJS при внезапной «смерти» процесса.

Автор сего чуда — Томаш Янчук, работает в «Майкрософте», оперативно отвечает на тикеты с описаниями проблем.

Его наработку используем на «боевом» сервере — проблем пока не выявили.
А драйвера для MS SQL Server не присоветуете? Гугль молчит как рыба об лед, толковых решений не предлагает. Их что, вообще не существует!?
Нет. Насколько я могу судить, пока что это мало кого интересует.
К сожалению, не присоветую — у нас MуSQL.
Может тогда попробуете наше решение? Мы не работаем в Майкрософте, но Helicon Zoo намного лучше iisnode. И по скорости и по надежности и по возможностям, да и устанавливать проще.
Ярослав, а можно где-то почитать, что умеет Helicon Zoo в применении к NodeJS?
Вы говорите «намного лучше и быстрее» — интересует, чем именно и какие то сравнительные тесты.

Меня в IISNode радует возможность «прятать» внешний порт, в примере Вашей статьи порт виден наружу. Посмотрел официальный сайт — там о такой возможности ничего не увидел :(.

Может, плохо смотрел?
Если вы про скриншоты, то там порт IIS Express, к Node.js он отношения не имеет.

Разумеется все так и работает. Helicon Zoo — это такой HTTP/FastCGI прокси со встроенным балансировщиком и менеджером процессов. Преимущество в том что работает он автоматически — самостоятельно создает процессы node.exe (и не только) по мере необходимости (нагрузка и т.п.) и самостоятельно их ресайклит, и делает все это быстро.

Еще кстати через IIS с легкостью проксируется Comet, в продакшене. Больше не нужно запускать отдельный процесс для обработки long polling запросов.
Посмотрю надосуге.

А вообще, странно, что Майкрософт, вместо того, что бы придти к Вам с предложением, предпочитает переписывать заново.

«Еще кстати через IIS с легкостью проксируется Comet, в продакшене. Больше не нужно запускать отдельный процесс для обработки long polling запросов.» — что Вы имеете ввиду? У меня как раз Комет-подобное решение бегает под IISNode, никаких отдельных процессов, кроме ноды, я не использую.
Это было про Апач — у него были проблемы с проксированием Comet в продакшене. Т.к. на каждый запрос выделяется по процессу он не выдерживал нагрузки когда количество подключений возрастало. У Nginx помоему тоже была проблема с количеством подключений к бекэнду если проксировать через него comet.
А, безусловно.

Но подобную проблему под Apache и NGinx успешно решал автор VooDoo Chat при помощи своих mod_voc2 и mod_nginx еще в 2005-2006 годах.

Напрямую проксировать, естественно — это убийство сервера, так как веб-сервер держит открытый коннект на все время long pooling сессии.

Описанные выше модули как раз и учили веб-сервер «забывать» о таком соединении, не закрывая сокет.
Недавно хотел познакомится с Node.js и тут как раз подробная статья. Спасибо!
Вопрос: а какой смысл в ноде под вин на продакшне, если libev откатывается на использование select() (вернее, WSASelect()) и в связи с этим теряет всю привлекательность в производительности? Для разработки понятно, но тогда, на мой взгляд, окружение node.exe + nginx поднять проще.
Все же прочитайте тесты производительности в статье. Как бы удалось получить такой результат, если бы все было на самом деле так плохо?
Node.js официально использует libuv начиная с версии 0.6.0 и там все гораздо лучше.
libuv, насколько я понимаю, всего лишь обертка над libev и IOCP для унификации кроссплатформенного API. Т.е. никаких чудес производительности от нее ждать не приходится. Да и странно было бы это — насколько я знаю ничего подобного kqueue/epoll/etc. под вин нет и пока не планируется.

Ваши замеры производительности не совсем помогают оценить ситуацию, поскольку не дают информации о масштабируемости решения по возрастанию кол-ва запросов/времени.

Я не утверждаю, что селект сам по себе тормоз, он просто начинает проседать при определенном количестве опрашиваемых сокетов в силу архитектуры (необходимость использования битовой маски под каждый сокет).
Правильно, libuv — это обертка, которая на Unix использует libev, а на Windows использует IOCP.
IOCP — это аналог libev на Windows. Несмотря на то что технологически они совершенно разные, функционально это прямой аналог. Так что никаких select и прочих ужасов.

Вот только недавно статья об этом была: habrahabr.ru/blogs/nodejs/131944/
Может, все-таки аналог poll/epoll? Потому что libev, в свою очередь, лишь обертка на этими механизмами.

Странно, из всего, что я знаю про IOCP, у меня почему-то сложилось ощущение, что это лишь внутренний механизм реализации асинхронности сокетов и работать с ними нужно все равно через WSA*-функции. Видимо, я ошибаюсь.

К сожалению, не могу найти достаточно полной статьи по IOCP, если бы вы смогли поделиться ссылкой на описание внутренних механизмов его работы и парой примеров — был бы признателен.
Не скажу чего аналог, потому что они одинаково не похожи ни на libev ни на epoll, но задача у них — поддержка асинхронных операций ОС, в частности ввода-вывода.
Документации и правда очень мало. Вот что мне дал разработчик:

Вот про порты msdn.microsoft.com/en-us/library/windows/desktop/aa365198(v=vs.85).aspx
Так мы его создаем msdn.microsoft.com/en-us/library/windows/desktop/aa363862(v=vs.85).aspx
Так читаем msdn.microsoft.com/en-us/library/windows/desktop/aa364986(v=vs.85).aspx
CreateIoCompletionPort так же используется для ассоциировать сокет/файл с портом. (названа функция крайне не удачно)
Вот это вот наводит на некоторые размышления и сомнения:

NumberOfConcurrentThreads [in]

The maximum number of threads that the operating system can allow to concurrently process I/O completion packets for the I/O completion port. This parameter is ignored if the ExistingCompletionPort parameter is not NULL.

If this parameter is zero, the system allows as many concurrently running threads as there are processors in the system.

Знать бы как оно работает внутри…

Наглый вопрос: не могли бы вы сделать графики зависимости пропускной способности от кол-ва открытых соединений? Интересно, где находится «яма», после которой начинает проседать производительность (а она обязательно должна быть :)).
«NumberOfConcurrentThreads [in]» — это число потоков, обслуживающих СР. Если они неблокирующие, то их нужно столько сколько ядер. Увеличение их числа не приведет к приросту производительности, а значительное увеличение даже снизит ее (накладные расходы).

По тесту попробую что ни будь придумать, но не обещаю. Такое количество соединений нужно еще чем-то генерировать, а у нас тут не ВЦ. И велика вероятность упереться в яму на клиенте/транспорте, т.е. будет неизвестно что же на самом деле померяли.
Есть же средства стресс-тестирования, pylot, например. При правильной настройке он и графики сам нарисует. Думаю, многие, включая меня, были бы вам весьма благодарны.

Не совсем понятно, что входит в «обслуживание». Значит ли это, что каждый поток последовательно обрабатывает какую-то часть дескрипторов по таймаутам, или же действует какой-то другой, еще более низкоуровневый, механизм работы с асинхронными дескрипторами.
Вот это вот наводит на некоторые размышления и сомнения:

NumberOfConcurrentThreads [in]


На самом деле не должно. Ожидать более, чем «there are processors in the system» не имеет смысла. Следует понимать, что на IOCP можно заблокировать и больше, чем NumberOfConcurrentThreads потоков, но они не

Знать бы как оно работает внутри…


Внутри все довольно просто. Пишу по памяти, так что могу напутать с деталями, но в общих чертах все должно быть правильно.

DISPATCHER_OBJECT (в общем все, что можно ждать при помощи NtWaitForXxxObject, в том числе и файлы) можно ассоциировать с очередью (KQUEUE). Когда объект переводится в signaled state (файлы «сигнализируются» когда завершается операция ввода/вывода для этого файла), в эту очередь, если она есть, добавляется wait-блок. GetQueuedCompletionStatus (вернее его native помощник NtRemoveIoCompletion) блокируется пока в этой очереди не появится чего нибудь.

Если еще короче, в объекте-IOCP есть очередь, а в файлах, ассоциированных с этим IOCP есть указатель на эту очередь. Вот и вся история.

Отвечая на начальный вопрос, WSAXxxSelect (и синхронный select) и IOCP — совершенно разные подходы, причем IOCP более изящный и зачастую более производительный. select отмечает момент времени, когда можно произвести «блокирующее» чтение/запись в файл без, собственно, блокирования (например, когда есть данные в буфере для recv) и предназначен для работы с этими синхронными версиями (send/recv/etc).

В то же время IOCP позволяет определить момент завершения асинхронной операции, требует использования асинхронных вызовов (WSASend/WSARecv/etc), позволяет избавиться от промежуточной буферизации: TCP/IP стек может копировать данные прямо в ожидающий пользовательский буфер, а в случае TOE пользовательский буфер может быть заполнен прямо сетевой картой по DMA. В случае send (и других операция тоже, включая recv, просто для send выгода не так очевидна), настоящие асинхронные операции позволяют опять же избавиться от промежуточного буфера (TCP/IP может «владеть» пользовательским буфером без необходимости срочно скопировать его куда нибудь и отпустить поток), а также это позволяет избавиться от задержек (latency) между готовностью к выполнению следующей операции и собственно выполнением этой операции: приложение может запостить несколько операций чтения/записи подряд — подход, используемый например в высокопроизводительной графике, для снижения задержек (double/triple-buffering).
О, спасибо за развернутый ответ!
Осталось переварить и понять, почему технология времен NT 3.5 так непопулярна была.
Перечитал. Несколько сумбурно (не быть мне tech writer-ом), а в одном месте вообще мысль оборвалась (все не могу выработать привычку перечитывать перед нажатием на «submit»), но в целом мысль должна быть ясна.

На всякий случай попробую прояснить суть с другой стороны: важно понимать отличие асинхронной операции от неблокирующей. Неблокирующие операции просто обязаны вернуться сразу же: если они не могут выполнить что-нибудь осмысленное, то они могут вернуться с ошибкой (например, EWOULDBLOCK). Асинхронная же операция это такая, которая может выполняться «в фоне», то есть операция выполняется всегда: если можно выполнить сразу — выполняем сразу, если нельзя — *инициируем* операцию и возвращаемся сразу. Все асинхронные операции неблокирующие, но не все неблокирующие операции асинхронные.

Из этой разницы и следует разница между IOCP и select. IOCP работает с асинхронными операциями и позволяет отреагировать на завершение операции, инициированной где-то в другом месте. select же (в том числе и «асинхронная» версия САМОГО select — WSAXxxSelect) работает с (не)блокирующими операциями. То есть можно создать «неблокирующий» сокет, recv (или read) из которого будет всегда возвращать ошибку, если в буфере пусто, но запостить собственный буфер для ожидания в него данных нельзя.

Насчет непопулярности спорно. Технология всегда была весьма популярна в high-load Windows приложениях. За пределами high-load использование асинхронности просто не имело смысла (ее труднее понять а если выгода неочевидна, то использование синхронных вызовов попросту легче). А за пределами Windows все по разному: на BSD/Solaris были свои аналоги, на Linux же поддержки асинхронных операций вообще не было до относительно недавнего времени (а как по мне, их и сейчас толком нет).
А что такое ubunthu?
После изучения графиков тоже стало интересно :)
Это опечатка.
Использовали Ubuntu Server 11.04 x64.
Я понимаю, что опечатка.

Сейчас релоаднул графики — все еще «Ubunthu».
Усли бы не верхний бар в WebMatrix получился неполохой такой редактор. Его можно как то спрятать?
intellisense работает для node и других языков?
Хм… Вы что до этого никогда Ribbon-интерфейс не видели? Он сворачивается по двойному клику на табе.
> Особенно приятно, что Node.js одинаково хорошо как на Unix, так и на Windows, и использует правильные для каждой из этих операционных систем технологические решения, что отчетливо видно по результатам тестов.

Ubuntu не Unix. Давайте тесты на FreeBSD, Gentoo, CentOS и Debian. Мне кажется, что у кого-то руки из жопы растут :)
линукс вообще не юникс. кроме того, ваше утверждение о том, что убунту чем-то хуже остальных дистров без аргументов не состоятельно
неоптимальные дефолтные конфиги. Windows с NTFS при всем своем желании не может быть быстрее Linux с EXT4. Уж проверяли, знаем.
конфиги это конфиги, так можно дойти до того, что если в гноме обои фиговые — дистр плохой.
щас мы и спросим у автора что за величина у него измеряна и как так получилось
Я где-то говорил, что Ubuntu плохая? Я говорю о том, что тестировать нужно на всех дистрибутивах и брать среднее значение. А тут какой-то вброс.
скажите, пожалуйста, вот у вас нарисованы какие-то диаграммы в каком-то редакторе по каким-то данным — назревают вопросы:
1. что за величина на графике изображена? попугаи какого цвета? с какими конфигами были достигнуты такие результаты на апаче и винде?
2. почему вы нарисовали это всё в каком-то табличном процессоре, в то время как у ab есть встроенная возможность экспорта данных в формат понятный GNUPlot для построения честных кривых?

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

*на апаче на линуксе и винде
Хорошо, дайте нам несколько дней — постараемся сделать более подробные графики. Заодно опечатку исправлю раз она так глаза мозолит.
Попугаи на графиках — запросы в секунду.
ещё конфиги там и там очень интересуют, подозреваю, что они совсем не одинаковые
Только что обновил статью с графиками и конфиги приложил. Смотрите.
Ждем запуска Node.js на Denwer…
Это не шутка!..
Добавьте у статьи тег «javascript».
Запускаю сайт, получаю ошибку:
500. Oops, something wrong in FastCgi module

Can't connect to a child process. Please, check configuration.
Операция успешно завершена.
dwError=0
TcpTransport.cpp: 108

Кто-нибудь сталкивался с такой?
Да. Эта ошибка означает что Zoo запустил воркер (в данном случае очевидно node.exe), но так и не дождался от него ответа. Причин может быть миллион — от синтаксической ошибки в скрипте запуска сервера, до недостаточных прав на папку с модулями или скриптами. Напишите нам в поддержку, постараемся выяснить в чем дело — support.helicontech.com/
Да, судя по «Операция успешно завершена.» это русская винда и вы видимо запускаете IIS Express? Node.js не понимает русские символы в пути к скриптам и падает, а т.к. сайты IIS Expres по умолчанию находятся в «Мои документы», то тут все и падает. Мы не можем это исправить со своей стороны, это ошибка Node.js.
Спасибо за ответ, но после переустановки Win, все заработало.
К сожалению проблема осталась. Однако если запускать код не из среды, то вроде работает. Вот пример:
var http = require('http');
http.createServer(function (req, res) {
res.writeHead(200, {'Content-Type': 'text/plain'});
res.end('Hello World\n');
}).listen(8000);
console.log('Server running at 127.0.0.1');


Если через cmd запускаю так: node.exe server.js, то запускается нормально. Если тот же скрипт запускаем из среды, то запускается браузер однако ничего не происходит. Браузер показывает индиатор загрузки, но этот процесс не прекращается.
.listen(8000);
заменить на
.listen(process.env.PORT);

в статье об этом есть.
Хотя, опять же повторюсь, с проблемами пишите к нам на суппорт. Хабр — не место для расследований проблем.
С появлением WebMatrix 2 Beta приложение Web Platform Installer обновилось до 4-й версии и ваш фид не подтягивает. А 3-ю версию уже не поставить
Да, для WebPI 4.0 нужно использовать фид по адресу www.helicontech.com/zoo/feed/4/
Microsoft вкурсе проблемы, они обещали в RC версии WebMatrix 2 исправить. Когда исправят — будет один фид для всех версий.
что-то или я тупой, или лыжи не едут.

Поставил на ВМ2 ноде темплейт, получил хеллоу, но когда пытаюсь вставить код из примера сервер отдает закешированную версию (хеллоу). Но в ВМ2 кнопки рестарт нету
В предыдущей версии могли быть проблемы со слежением за изменениями *.js файлов. Пожалуйста обновите версию Zoo Module: Zoo -> Modules -> Helicon Zoo Module for IIS Express — просто нажать установить еще раз. WebMatrix нужно будет перезапустить.
Если и это не поможет, то в web.config в секцию добавьте строку:
/>
Просто под WebMatrix 2 Beta у нас пока нет автотестирования, но это временно.
Теги скушались. Нужно так:
<environmentVariables>
<add name="WATCH_FILE_CHANGES_MASK" value="*.js" />
похоже проблема была в «Мои документы».

Вы так быстро отвечаете… можно еще вопрос? Как сделать coffeescript? Модуль-то для линукса тянется из ryppi
К сожалению с coffescript сильно не помогу т.к. сам не очень разбираюсь. Модуль который устанавливается работает на Windows, но не работает команда coffee из командной строки (хотя и ее как-то можно уговорить скорее всего). Само применение которое рекомендуют в документации включает в себя запуск слежения за изменениями файлов, очевидно отдельным процессом node.exe. Мне же кажется что вызов компиляции .coffee файлов прямо из кода будет более надежным решением. В любом случае тут нужно делать обертку (возможно она уже есть, но я о ней не знаю). Спросите на более специальном форуме, возможно там подскажут.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории