Вышел (http://blog.nodejs.org/2013/03/11/node-v0-10-0-stable/) стабильный релиз Node.js 0.10 (http://nodejs.org/), платформы для выполнения высокопроизводительных сетевых приложений на языке JavaScript. Платформа может быть использована как для серверного сопровождения работы Web-приложений, так и для создания обычных клиентских и серверных сетевых программ. Для расширения функциональности приложений для Node.js подготовлена большая коллекция модулей (https://github.com/ry/node/wiki/modules), в которой можно найти модули с реализацией серверов и клиентов HTTP, SMTP, XMPP, DNS, FTP, IMAP, POP3, модули для интеграции с различными web-фреймворками, обработчики WebSocket и Ajax, коннекторы к СУБД (MySQL, PostgreSQL, SQLite, MongoDB), шаблонизаторы, CSS-движки, реализации криптоалгоритмов и систем авторизации (OAuth), XML-парсеры.Для обеспечения обработки большого числа параллельных запросов Node.js задействует асинхронную модель запуска кода, основанную на обработке событий в неблокирующем режиме и определении callback-обработчиков. В качестве способов мультиплексирования соединений поддерживаются такие методы, как epoll, kqueue, /dev/poll и select. Для мультиплексирования соединений используется библиотека libuv (https://github.com/joyent/libuv/), которая является надстройкой над libev (http://software.schmorp.de/pkg/libev.html) в системах Unix и над IOCP в Windows. Для создания пула потоков (thread pool) задействована библиотека libeio (http://software.schmorp.de/pkg/libeio.html), для выполнения DNS-запросов в неблокирующем режиме интегрирован c-ares (http://c-ares.haxx.se/). Все системные вызовы, вызывающие блокирование, выполняются внутри пула потоков и затем, как и обработчики сигналов, передают результат своей работы обратно через неименованный канал (pipe). Выполнение JavaScript-кода обеспечивается через задействование разработанного компанией Google движка V8 (http://code.google.com/p/v8/).
По своей сути Node.js похож на фреймворки Perl AnyEvent (http://search.cpan.org/dist/AnyEvent/), Ruby Event Machine (http://rubyeventmachine.com/) и Python Twisted (http://twistedmatrix.com/), но цикл обработки событий (event loop) в Node.js скрыт от разработчика и напоминает обработку событий в web-приложении, работающем в браузере. При написании приложений для node.js необходимо учитывать специфику событийно-ориентированного программирования, например, вместо выполнения "var result = db.query("select..");" с ожиданием завершения работы и последующей обработкой результатов, в Node.js использует принцип асинхронного выполнения, т.е. код трансформируется в "db.query("select..", function (result) {обработка результата});", при котором управление мгновенно перейдёт к дальнейшему коду, а результат запроса будет обработан по мере поступления данных. Ни одна функция в Node.js не должна напрямую выполнять операции ввода/вывода - для получения данных с диска, от другого процесса или из сети требуется установка callback-обработчика.
Наиболее заметные новшества (https://github.com/joyent/node/wiki/Api-changes-between-v0.8...), добавленные в Node.js 0.10:- Новая реализация API для работы с потоками ввода/вывода - Streams2 (http://blog.nodejs.org/2012/12/20/streams2/), устраняющая некоторые ранее проявляющиеся проблемы, такие как невозможность прочитать только фиксированное число байт, оставив остальную часть потока для дальнейшей обработки. Кроме того, новая система позволила перевести все потоки в ядре Node.js на использование единого набора легко расширяемых классов, а также упростила создание потоковых интерфейсов в пользовательских приложениях. Новое API Streams2 также доступно в виде модуля readable-stream (https://npmjs.org/package/readable-stream) для прошлых выпусков Node.js, при этом 37 модулей в репозитории уже используют (https://npmjs.org/browse/depended/readable-stream) данный API;
- Модуль domain (http://nodejs.org/api/domain.html), позволяющий связать несколько разных операций ввода/вывода и выполнить их обработку в виде единой группы, зафиксирован в плане функциональности и переведён из разряда экспериментальных в категорию нестабильных, а в будущем будет позиционирован как стандартный способ обработки ошибок в Node.js;
- Проведена большая работа по оптимизации производительности, что отразилось в заметном ускорении выполнении тестов, по сравнению с веткой 0.8. Некоторые тесты, особенно связанные с вводом/выводом и шифрованием, в новой версии выполняются быстрее в разы;
- Изменен способ обработки функции process.nextTick(), которая теперь не привязана к циклу обработки событий и не зависит от операций ввода/вывода. Новая реализация process.nextTick() отличается соблюдением точности callback-вызова, вне зависимости от интенсивности ввода/вывода;
- Переработана работа сборщика мусора, активация которого стала более предсказуемой. Если ранее сборщик мусора пытался планировать запуск чистки с оглядкой на состояние памяти и простой системы, из-за чего было невозможно предсказать, когда он активируется и как долго будет выполняться, особенно на нагруженных системах, то в новой версии логика вызова сборщика мусора ложится целиком на JavaScript-движок V8, который достаточно продвинут в плане самостоятельной организации чистки мусора. В результате, отзывчивость система стала более постоянной и предсказуемой.
Следующим этапом развития Node.js станет выпуск 0.12, в котором будет сделан акцент на улучшении реализации поддержки HTTP и, возможно, в качестве базовой реализации TLS будет возвращён модуль tlsnappy (https://github.com/indutny/tlsnappy). После этого начнётся подготовка знакового релиза 1.0, который ознаменует собой определённую завершённость базовой функциональности, стабилизацию API и переход к более жёстким критериям обеспечения обратной совместимости.
URL: http://blog.nodejs.org/2013/03/11/node-v0-10-0-stable/
Новость: http://www.opennet.ru/opennews/art.shtml?num=36366
Копировать файлы не через гланды там всё ещё никак?
> Копировать файлы не через гланды там всё ещё никак?pipe() https://github.com/nodeca/fs-tools/blob/master/lib/fs-tools.... . Ну или какой-нибудь микромодуль возьмите, их навалом. Не та проблема, в общем.
> Копировать файлы не через гланды там всё ещё никак?А напуркуа вам асинхронный сервер приложений для этой цели?
ой да ладно ассинхронный, однопоточное тормозилово к которому пытаются пристегнуть множество потоков ввода вывода которые все одно ждут этот один поток.
очередной быдлонетовский неосилятор :)
офигенные аргументы. я продукты дяди билла не пользую
Причем здесь Уильям Г.? Или вы о ком-то другом?
> ассинхронныйасинхронный. ass - это ты.
> однопоточное тормозилово
Лол. nginx вон однопоточный - рассказать как он рвёт апачи и прочую чушь аж с несколькими моделями параллельности?
> одно ждут этот один поток
Никто там никого не ждёт, лол.
> nginx вон однопоточныйОн не однопоточный, он мультиплексирующий многопоточный.
> рассказать как он рвёт апачи
За счёт и других отличий, помимо модели обработки соединений.
>>> рассказать как он рвёт апачиНу расскажи. Условие - динамика/CGI, или PHP как модуль (lol).
>>>> рассказать как он рвёт апачи
> Ну расскажи. Условие - динамика/CGI, или PHP как модуль (lol).php, как модуль nginx o_O ? :)
А вообще тут разговор не о запускании php, а об обработке соединений, c которой nginx справляется на отлично (за счет epoll/kqueue).
apache с mpm-event не тестировал, поэтому сравнить не могу.
> php, как модуль nginx o_O ? :)Именно. Хотелось послушать, как nginx порвёт апач в данном случае :)
> А вообще тут разговор не о запускании php, а об обработке соединений
Одно дело отдавать лежащие на диске / в кешах статические элементы / проксировать, и совсем другое - собственно обработка логики. Для последней задачи nginx совершенно не предназначен, и "порвать" полноценные серверы на этом поле не то что не сможет, а просто не умеет.
> c которой nginx справляется на отлично (за счет epoll/kqueue).Не за счёт epoll/kqueue. За счёт однопоточной модели обработки запросов (воркеры возможны, но это де факто все равно одиночные потоки) по принципу конечного автомата. Очень хорошо тогда, когда сам сервер может определять timeslice для отдачи блоков, и никак для динамики, когда все равно надо запускать дочерние процессы.
> apache с mpm-event не тестировал, поэтому сравнить не могу.
А это делать бесполезно. nginx - скорее "болид F1", а Apache - "БелАЗ". Разные весовые категории и применения :) Первый заточен на скорость по специальной трассе, второй - на проходимость и решение сложных задач :)
>> php, как модуль nginx o_O ? :)
> Именно. Хотелось послушать, как nginx порвёт апач в данном случае :)Никак. Под nginx нет модуля php)
Мне кажется, мы с вами уже дискутировали ранее насчет nginx vs apache в плане работы с php.
Поэтому, давайте кратко.
Если для вас apache+mod_php работает лучше, чем nginx+php-fastcgi, ради бога используйте его.
Если вы хотите убедить в этом других, предоставьте что-то кроме своих слов.
Мне самому интересно было бы посмотреть, в каком случае это так.
У вас есть ссылка на статью или обсуждение с замерами?
> Мне кажется, мы с вами уже дискутировали ранее насчет nginx vs apacheНет.
> Если вы хотите убедить в этом других, предоставьте что-то кроме своих слов.
Лично пресловутого анонима я ни в чём переубеждать не хочу. Фанатичные пользователи наколенных поляпок только потому "что они где-то там (где есть штат программистов пилить вечную бету) рвут всех" ничего, кроме сочувствия, никогда не вызывали.
Вкратце: если мне надо будет отдать много прокси/статики - я выберу nginx. Ибо шансов завалиться у него на такой конфигурации немного, и модель отдачи подходящая. Если много динамики (хоть PHP, хотя Java, хоть еще чего) - Apache - из-за процессной модели, устойчивой к обвалам. Если ASP - IIS, из-за безвариантовости. А пытаться ездить на Ламборджини по проселочной трассе с прикрученными метровыми квадратными колёсами (угу, FastCGI)...
> Если много динамики (хоть PHP, хотя Java, хоть еще
> чего) - Apache - из-за процессной модели, устойчивой к обвалам.У вас были прецеденты, где обваливался nginx, а Apache держал нагрузку?
> У вас были прецеденты, где обваливался nginx, а Apache держал нагрузку?Не только прецеденты, но и вполне реальные грабли.
segfault в apache/prefork(itk) - это смерть одного соединения.
segfault в nginx - это смерть всех текущих соединений. Разница легко ощутима.
> segfault в apache/prefork(itk) - это смерть одного соединения.
> segfault в nginx - это смерть всех текущих соединений. Разница легко ощутима.о_О и часто у Вас apache и nginx сегфолтятся?
>> segfault в apache/prefork(itk) - это смерть одного соединения.
>> segfault в nginx - это смерть всех текущих соединений. Разница легко ощутима.
> о_О и часто у Вас apache и nginx сегфолтятся?nginx с динамикой сегфолтился каждый второй день. Это было на бородатой 0.8.2. А еще страшно не умел chunked. После этого было решено им пользоваться только для проксей и фронтендов - на статике не падает.
На критичных участках даже на фронтах - апач с worker/event. Сейчас ситуация могла измениться, но в целом даже тестирование уже не окупится - смысла ломать стабильно работающие узлы нет.
Опять же - да - ситуация личная. В моем случае проще (и дешевле!) смасштабироваться горизонтально, чем пытаться допилить вечную бету для хайлоада до рабочего состояния. Ну и нет у меня задач с приоритетом оптимизации нагрузки - есть задачи с приоритетом стабильности и поддерживаемости сторонними лицами.
> nginx с динамикой сегфолтился каждый второй день. Это было на бородатой 0.8.2.
> А еще страшно не умел chunked. После этого было решено им
> пользоваться только для проксей и фронтендов - на статике не падает.Добрый день.
Простите за интерес, а какие у Вас (хоть ориентировано) показатели нагрузки ?
В плане к-ва запросов, трафика и т.д. ?
Мне интересно как общего развития, т.к. у меня динамику отдает Tomcat, спрятанный за nginx ...
>> У вас были прецеденты, где обваливался nginx, а Apache держал нагрузку?
> Не только прецеденты, но и вполне реальные грабли.
> segfault в apache/prefork(itk) - это смерть одного соединения.
> segfault в nginx - это смерть всех текущих соединений. Разница легко ощутима.Вообще segfault - это уже само по себе плохо.
И всегда можно откопать причину, с помощью gdb, strace и т.д.Потом, у nginx можно задать несколько процессов-обработчиков.
Да, есть один master, как и у apache, но он врядли упадет (как и у apache).И потом, nginx общается с динамикой не внутри своего процесса, а через fcgi/wsgi/proxy/...
Скажем, если упадет процесс php-fpm, процессу nginx от этого ничего не станет, он просто передаст запрос следующему процессу, или серверу в upstream.
Например недавно был баг в pinba, изза которого php процесс падал в segfault при авторизации на сайте.
php процесс падал, а nginx спокойно передавал запросы дальше.
В том и плюс nginx, что он динамику внутри себя не обрабатывает, он занимается передачей запросов - сам он не страдает от падучести динамики.
Имейте это в виду при дальнейшем росте.
> Вообще segfault - это уже само по себе плохо.Именно. Но в случае динамики у Вас оно может быть достаточно легко, потому что объём выполняемого кода достаточно велик. Это не проксирование/статика.
> Потом, у nginx можно задать несколько процессов-обработчиков.
> И потом, nginx общается с динамикой не внутри своего процесса, а через
> fcgi/wsgi/proxy/...И всё это печально одним... нет, даже двумя моментами.
а) Apache - очень хороший менеджер процессов, куда лучше, чем во многих имплементациях FCGI. В частности PHP как FCGI лучше даже не рассматривать.
б) Если у Вас падает воркер или FCGI - всё становится невесело. Потому, что обрываются ВСЕ запросы, связанные с данным воркером/FCGI-процессом. А не один упавший. В случае FCGI еще и рестартер держать придётся.У Apache в данном случае еще одно преимущество - корневой процесс минималистичный, вылизывался годами сотнями людей, и шанс его падения близок к 0. Поэтому доверия к нему куда больше, чем к nginx+FPM/FCGI.
А в общем да - я с вами согласен. nginx - неплохой фронтенд (хотя и сырой, имхо). На бэкендах будет всегда оставаться что-то иное.
---
Еще немножко оффтопа, пожалуй.
Не зря у пользователей nginx часто ассоциируется с 502. 502 в нашем случае - это не вина nginx - это ошибка бэкенда. Но вся суть в том, что при использовании FCGI/FPM/... вся система получается несколько более падучей. Не только из за числа компонентов, но и из-за сравнительной ненадежности реализации.
По факту - nginx _очень_ хорош для масштабных применений - в качестве load balancer к десяткам worker backends. Когда его ляпают на каждый чих из-за фанатизма - это дает хреновый результат.
Я всегда сравниваю nginx с FreeBSD в этом плане - такое же мелкое нишевое "самопальное" решение, которое в России почему-то пытаются воткнуть каждой бочке затычкой, получая пачки костылей и крайне ненадежные системы. И лишь единицам с приличным выделенным штатом под костылинг удаётся добиться реальных результатов, причем иногда - выдающихся.
> И всё это печально одним... нет, даже двумя моментами.
> а) Apache - очень хороший менеджер процессов, куда лучше, чем во многих
> имплементациях FCGI. В частности PHP как FCGI лучше даже не рассматривать.
> б) Если у Вас падает воркер или FCGI - всё становится невесело.
> Потому, что обрываются ВСЕ запросы, связанные с данным воркером/FCGI-процессом. А не
> один упавший. В случае FCGI еще и рестартер держать придётся.
> У Apache в данном случае еще одно преимущество - корневой процесс минималистичный,
> вылизывался годами сотнями людей, и шанс его падения близок к 0.
> Поэтому доверия к нему куда больше, чем к nginx+FPM/FCGI.Вообще-то для FCGI уже есть php-fpm.
У php-fpm корневой процесс - тоже самое, что у apache, так же занимается минимумом дел.
И от ошибок дочерних процессов не падает.> Я всегда сравниваю nginx с FreeBSD в этом плане
А Apache - это linux типа?
У руби и перла есть Phusion Passenger к nginx
А в ноде это безысходность из соплей
> У рубиверсия == 1.9.x
у nodejs
версия == 0.10phusionpassenger.com:
- WSGI support is in beta
- Node.js support is coming up nextможет пора таблетки принять и прекратить истерику?
и таки где перл? ткни носом, пожалуйста. или ты про WSGI?
У Perl'а свой велосипед - PSGI.
> У руби и перла есть Phusion Passenger к nginx
> А в ноде это безысходность из соплейPhusion Passenger - вот это точно от безысходности.
С nodejs можно работать через обычный proxy_pass.
Через обычный proxy_pass можно работать и с Руби. Тема высосана из пальца.
Ребята как можно в здравом уме и памяти применять клиентский язык на сервере? У него тысяча способов отстрелить себе ногу. Использование динамических языков на сервере я лично считаю очень плохим решением.
Проблемы у этих ребят не в неправильном выборе языка.
Очень забавлял баг когда GC тормозил выполнение VM на 5 сек периодически.
Хотя для клиента фича годная. Вообще ждем dart.
> Ребята как можно в здравом уме и памяти применять клиентский язык на сервере?1. Что такое "клиентский язык" ? Пожалуйста, определение.
2. Что такое "сервер"? Как относиться к запросам "серверного языка", например, к той же БД, к DNS, да хоть к файловой системе? Они серверные или нет?> У него тысяча способов отстрелить себе ногу.
у каждого человека -- миллионы таких способов.
> Использование динамических языков на сервере я лично считаю очень плохим решением.
А что такое "динамический язык", видимо, некая противоположность "статическому"? Приведите пример "статического" языка и "хорошего решения".
Хотя, похоже, с вашими познаниями о языках лучше вам писать на форуме филфака.
> Как относиться к запросам "серверного языка", например, к
> той же БД, к DNS, да хоть к файловой системе?Относиться стоит сдержанно. :)
> Хотя, похоже, с вашими познаниями о языках лучше вам писать на форуме филфака.
При всём уважении -- но и у филфака нам можно поучиться языковой грамоте; http://tsya.ru
А вообще да, претензия к динамическим языкам была крайне невнятной.
Да ну всё это к лешему. Михаил лучше скажи, как человек посматривающий по сторонам, есть где тфтп с скриптованием по событию? Вот файлик залили - надо один скрипт пиннуть, слили другой - ещё один скрипт пнули.
> есть где тфтп с скриптованием по событию?Не встречал; погулил наскоро "scripted tftpd" -- не клюёт, а вот на "smart tftpd" под конец первой страницы выдачи нашёлся https://lists.fedorahosted.org/pipermail/cobbler-devel/2010-... -- гляньте, может, ближе к нужному. Изменяя тему ответа, понял, что искать стоило "tftpd with hooks" -- вроде тоже что-то есть, посмотрите уж сами.
Вот-вот. И спрашивается: как хранят конфиги железок админы? Лично мне кажется правильным поднять какую-нибудь vcs и туда tftp сливает конфиги. А после приёма файлика дёргает коммит скриптом. Вот ты нашёл что-то довольно тяжёлое для такой простой вещи. Снизу предлагают самому навелосипедить. Это конечно тоже вариант. Но разве никто в мире не делал такую простую вещь? Странно что нет ничего из_коробки для таких вариантов.
> Вот-вот. И спрашивается: как хранят конфиги железок админы?Не железкоадмин -- возможно, лучше отловить pilot на #altlinux и спросить, как по уму.
> Да ну всё это к лешему. Михаил лучше скажи, как человек посматривающий
> по сторонам, есть где тфтп с скриптованием по событию? Вот файлик
> залили - надо один скрипт пиннуть, слили другой - ещё один
> скрипт пнули.Не Михаил, но тоже внесу свои 5 копеек - реализация протокола крайне простая, можно написать самому (или взять готовый модуль). Я когда озадачился этой проблемой, взял http://wiki.tcl.tk/12711 и дописал чуть кода. Заняло времени меньше, чем поиск готового решения =)
> Да ну всё это к лешему. Михаил лучше скажи, как человек посматривающий
> по сторонам, есть где тфтп с скриптованием по событию? Вот файлик
> залили - надо один скрипт пиннуть, слили другой - ещё один
> скрипт пнули.inotify в лице inncron чем не угодил?
afaik, событие CLOSE_WRITE
nodejs это модно и молодежно!
erlang же. Всё остальное ломанные костыли.
Эрланг уже пошло и ни разу не молодежно
Это на нем работает mail.ru ? xDDD
Какая разница что вы там считаете если заказчик платит за скорость разработки. А то касается производительности, так вроде 2013 год на дворе.
там скорость разработки только готовое пристегнуть или веб сервер в три строки, а как что то серьезное начинаешь писать сразу понимаешь что можно было сто раз на другом все это написать
> Ребята как можно в здравом уме и памяти применять клиентский язык на сервере?Нет такого понятия как "клиентский язык". javascript можно применять везде, и ниша у него пошире будет чем, например, у многих устоявшихся скриптовых языков. И производительность повыше.
> У него тысяча способов отстрелить себе ногу.
Как и у любого языка, включая "ынтерпрайз стандарты".
> Использование динамических языков на сервере я лично считаю очень плохим решением.
И кому есть дело до твоего мнения?
Мне всегда было интересно, как применять Twisted без генераторов Python. Писать сколько-нибудь сложную логику на callback'ах -- мучение. Другое дело, когда используешь генератор, который в тех местах, где нужно ждать callback'а, выдаёт из генератора объект.А там всё действительно только на callback'ах? Поскольку языкового механизма вроде бы нет.
>> Писать сколько-нибудь сложную логику на callback'ах -- мучение.С модулем "async" легко и непринужденно.
Посмотрел на https://github.com/caolan/async/blob/master/test/test-async.js. По первому впечатлению, тоже не очень удобно. В Twisted это делается с использованием defer.deferredGenerator, при этом пишется обычный код (локальные переменные, ветвления и циклы используются без ограничений), и только точки разрыва оформляются как yield. К сожалению, в JS нет языкового механизма, чтобы, сохранив стек и все переменные во всех областях видимости по этому стеку, продолжить выполнение в другом месте, а впоследствии вернуться. Что, вообще говоря, жаль. Впрочем, справедливости ради скажу, что Twisted, конечно, тоже не образец простоты... Но после однократного освоения такие вещи там делаются на порядок проще.
Дело привычки, не более :)
С этим трудно не согласиться. :-)
> Посмотрел на https://github.com/caolan/async/blob/master/test/test-async.js. По
> первому впечатлению, тоже не очень удобно. В Twisted это делается с
> использованием defer.deferredGenerator, при этом пишется обычный код (локальные переменные,
> ветвления и циклы используются без ограничений), и только точки разрыва оформляются
> как yield. К сожалению, в JS нет языкового механизма, чтобы, сохранив
> стек и все переменные во всех областях видимости по этому стеку,
> продолжить выполнение в другом месте, а впоследствии вернуться. Что, вообще говоря,
> жаль. Впрочем, справедливости ради скажу, что Twisted, конечно, тоже не образец
> простоты... Но после однократного освоения такие вещи там делаются на порядок
> проще.Для ниасиляторов есть node-fibers. Но лично я таким советую php.
> Для ниасиляторов есть node-fibers. Но лично я таким советую php.Проблема совсем не в том, что это трудно "осилить". Человек, который "осиливает" сопрограммы, заведомо "осилит" и callback'и. Для этого не требуется семи пядей во лбу, сложного-то ничего в них нет. Проблема в том, что получается громоздко.
На чистом C тоже можно писать объектно-ориентированные программы, и их пишут, что характерно (и иногда это вполне оправданно). И до тех пор, пока не нужно сложных вещей, это будет работать, порой не хуже, чем на C++. Но когда потребуется выбор вызываемой функции в зависимости от реального класса объекта (не от типа указателя, а от того, что по этому указателю лежит), придётся изобретать замену готовому механизму виртуальных функций и каждый раз писать обращение к ней. Так и тут.
Многа букф ниачом. Пора уже вместо рассуждений хоть что-то попробовать.
А вот node-fibers дейтсвительно даёт код, похожий на Питоновские генераторы.
> Посмотрел на https://github.com/caolan/async/blob/master/test/test-async.js. По
> первому впечатлению, тоже не очень удобно. В Twisted это делается с
> использованием defer.deferredGenerator, при этом пишется обычный код (локальные переменные,
> ветвления и циклы используются без ограничений), и только точки разрыва оформляются
> как yield. К сожалению, в JS нет языкового механизма, чтобы, сохранив
> стек и все переменные во всех областях видимости по этому стеку,
> продолжить выполнение в другом месте, а впоследствии вернуться. Что, вообще говоря,
> жаль. Впрочем, справедливости ради скажу, что Twisted, конечно, тоже не образец
> простоты... Но после однократного освоения такие вещи там делаются на порядок
> проще.Если уж зашла речь об асинхронно-событийной парадигме, то не стоит ли попробовать, к примеру, Tcl? Очень сильно развитая часть языка, при этом, использовать ее действительно просто. При этом, язык не столь экзотичен, как erlang (функциональное программирование все же многим людям непривычно). Если нравится использовать coroutine и yield - смотрите сразу на ветку 8.6, хотя я использую преимущественно 8.5 без yield и программировать все равно удобно.
> Если уж зашла речь об асинхронно-событийной парадигме, то не стоит ли попробовать,
> к примеру, Tcl?tcl умер ещё до перла. И синтаксис в нём ещё более отвратительный.
> tcl умер ещё до перла. И синтаксис в нём ещё более отвратительный.Это разве что для чайников, которых устраивает каждые пару лет лопатить свои тонны эээ... прелестного кода.
И синтаксис -- всего лишь следствие подхода, если кому испортили мозги бей^Wимперативщиной, ну так ему любой иной подход будет непривычен.
Erlang, кстати, мне очень нравится и к некоторым задачам моей команды подходит идеально. И вообще есть мечта пописАть на функциональном языке. А в Erlang, помимо функциональной парадигмы, есть ещё и очень эффективный параллелизм с легковесными процессами, которые можно создавать тысячами.К сожалению, трудно это намерение воплотить в жизнь по работе, т.к. не очень правильно писАть на том, что мало кто в компании знает, если это не даёт какого-то уж очень радикального выигрыша. А радикального не даёт, увы. Так уж вышло, что по работе мне вообще регулярно приходится убеждать людей не делать того, что самому хотелось бы (например, недавно один весьма уважаемый мною разработчик из другого отдела хотел прикрутить к проекту Haskell; это было бы очень красиво, но я его отговорил: ради той мелочи, которая была ему нужна, добавлять к проекту ещё один язык, тем более довольно "эзотерический", было бы не очень разумно). И, если уж поступать честно, то и самому приходится от подобных вывертов воздерживаться.
> К сожалению, трудно это намерение воплотить в жизнь по работе,
> т.к. не очень правильно писАть на том, что мало кто в компании знаетСпросите Нетча, он может рассказать про то, как у нас обучали отдел эрлангистов.
Да, история была бы интересна. Попробую.
или альтернатива - Step. только там нужно понимать, что делаете, ибо можно потерять контроль за потоком выполнения
Что за хрень вы несёте, в вашем twisted всё на обычных deffered объектах с такими же колбэками. На сколько мне известно вообще не существует других способов писать асинхронный код нежели использовать колбэки.
> Что за хрень вы несёте, в вашем twisted всё на обычных deffered
> объектах с такими же колбэками. На сколько мне известно вообще не
> существует других способов писать асинхронный код нежели использовать колбэки.О, прибежал типичный опеннетчик. Выучить Twisted времени нет, Питона толком не знает, а вот про хрень порассуждать и похамить всегда готов. Погуглите defer.deferredGenerator. Внутри там, конечно, callback'и, но снаружи это вообще не видно.
> На сколько мне известно вообще не существует других способовВы не правы. Следующий этап развития асинхронного программирования - короутины. http://ru.wikipedia.org/wiki/%D0%A1%D0%B...
Правда во многих языках поддержка либо номинальная, либо неудобная.
Хы! Читал-читал, думал что же это такое знакомое до боли проглядывает сквозь ворох академического словоблудия.... Конечно же greenlets! Ну, если так, то тема, без условно, годная - я знаю не один проект использующий эту методику и с очень хорошими результатами. Причем, один из таких проектов я постоянно употребляю на продакшине - это gunicorn http://docs.gunicorn.org/en/latest/design.html
вообще-то есть gevent.
> вообще-то есть gevent.Который как раз и использует gunicorn "The asynchronous workers available are based on Greenlets (via Eventlet and Gevent). " См. http://docs.gunicorn.org/en/latest/design.html
# Nginx + uWSGI
uwsgi_enable="YES"
#uwsgi_flags="-L -M --vhost"
А можно пруф на спецификацию протокола uWSGI?Потому как очень интересно:
- где/какими организациями этот протокол зарегистрирован
- какими продуктами (кроме сервера uWSGI) используется
- можно ли этот проткол (без мода) с nginx юзатьПотому что я без ответа на эти вопросы на продашене протокол как-то не привык юзать.
greenlets -- это то, что используется в gevent. И это ещё одно решение с близкими к Twisted функциями. То, что в Twisted сделано чисто Питоновскими сопрограммами на генераторах, там сделано на более низком уровне. И везде есть свои преимущества.На gevent/greenlets, по моему опыту, пишется легче, но отлаживается тяжелее (хотя IntelliJ Pycharm с некоторых пор умеет отлаживать такой код, большинство отладчиков не могут), а анализ покрытия кода тестами иногда выдаёт феерический бред. На Twisted код более громоздкий, но тестируется сравнительно легко. Утверждается, что gevent в связке с gunicorn позволяет эффективно параллелить работу, но этого я не делал, не было реальной нужды.
В общем, дело вкуса. Для обычных задач лично я больше люблю gevent, но для очень ответственных с параноидальными требованиями по надёжности -- Twisted.
> А там всё действительно только на callback'ах? Поскольку языкового механизма вроде бы
> нет.С помощью Reactive Extensions писать сложную бизнес логику проще чем на генераторах. https://github.com/Reactive-Extensions/RxJS
С помощью Reactive Extensions писать сложную бизнес логику проще чем на генераторах. Хотя это скорее не конкурирующий технологии, а приёмы, которые друг друга дополняют:
https://github.com/Reactive-Extensions/RxJSПример кода, который:
1. Читает данные из сокета
2. Находит сообщения в формате FIX и транслирует их в JSON
3. Результаты склеивает в список
4. Результат пишет в сокетFixPP.prototype.prettyPrint = function(req, res) {
req.readStream()
.toBuffer()
.select(this.findFixMessages.bind(this))
.concatObservable()
.subscribe(observerFromResponse(this.Rx, res));
};Код асинхронный неблокирующий
Код легко покрывается тестами
Код представляет из себя набор простых операторов, которые ты собираешь как конструкторЛично мне проще писать на JS чем на питоне, т.к. в JS есть нормальная лямбда
> Пример кода, который:что будет, если приедет невалидное из сокета или клиент просто отвалится?
вообщем, где обработка ошибок?> Лично мне проще писать на JS чем на питоне, т.к. в JS
> есть нормальная лямбдаа в python есть gevent и много чего ещё.
> что будет, если приедет невалидное из сокета или клиент просто отвалится?
> вообщем, где обработка ошибок?Обработка ошибок - это как раз одна из сильных сторон Reactive Extensions. В моем примере ошибка будет пробрасываться по цепочке и в результате клиент получит ответ { status: "error", details: .... }
Например, можно создать функтор (failover), который перехватывает ошибки и повторяет попытку через время, и так, например, три раза, если ошибка не прекращается - увеличивает таймаут и т.д. Теперь этот функтор можно комбинировать с любой асинхронной операцией:
file.readAll().failover(times(3), sec(15))
socket.read().failover(times(10), sec(15))
topic.readMessages().failover(times(3), sec(3))Дальше этот алгоритм можно покрыть тестами и прогнать их за одну милисекунду используя концепцию "виртуального времени" :). RX устроен таким образом, что вы не используете никаких Sleep-ов явно, а отправляете задачу в scheduler (ThreadPool, EventLoop, NewThread, Immediate ....) и указываете когда ее выполнить, поэтому в тестах как правило используется TestScheduler на котором время "течет" быстрее.
Библиотека спроектирована очень грамотно. Рекомендую ознакомительное видео http://channel9.msdn.com/Blogs/Charles/Erik-Meijer-Rx-in-15-...
Всякие futures, async, promises - это частный случай RX.
Еще очень легко управлять временем жизни ресурсов. Что делать, например, если возникла ошибка внутри сложного алгоритма или клиент нажал кнопку отмена и надо отписаться от событий, освободить ресурсы, но это уже тема для отдельного разговора ...
Да, по ощущению, это не лишено красоты, хотя мне не хватает знания контекста, чтобы оценить в полной мере. Впечатления конкурирующей технологии действительно не производит.
смотрится неплохо, но>There is no recommended release for this project.
>This project has no releases.
>This project does not have documentation yet. Visit the Discussions tab to ask questions....
Кроме того, у особых "ценителей", расположение проекта на кодплексе может вызывать необъяснимые приступы попоболи и баттхерта.мне очень интересен Rx++ в частности.
Решение интересное. хотя спорное .... надо будет пощупать, как оно по сравнению с рельсами ...
Щито?
Ваше сравнение будет не коректное. Из Ruby мира для сравнения скорее подходит event machine. А вобще nodejs часто используют вмете с какимто MVC фреймворком, например для того что б всторить на страничку чат. А вобще у меня складывается впечатление что nodejs это скорее для пхп-шников, так как в Python/Ruby есть свои годный асинхронные фреймворки.
Насчет пхп-шников согласен с выводами.
Образцами для разработчиков Node.js были EventMachine(Ruby) и Twisted(Python).
Как уже выше было совершенно верно подмечено.