takkmoil Oct 4 2011 at 01:43

Node.js — раковая опухоль

5 min

136K

Node.JS*

Translation

+394

335

Comments 335

hf35 Oct 4 2011 at 01:53

Вы просто ничего не понимаете в Node.js)
Ещё пади PHP считаете идеалом?

>>Это блядский JavaScript

вы будете гореть в аду)

takkmoil Oct 4 2011 at 01:58

Ааа, вы не знаете про Теда. Ну тогда поперевожу ещё. Кстати, у вас контраргументы есть?

kivsiak Oct 4 2011 at 02:29

Я не знаю. Хочу еще… Не ждать терпения не хватит пойду читать что за чувак такой. Приятно что есть и люди которые не ведутся на хайп вокруг асинхронных фреймворков

govorunov Oct 4 2011 at 02:41

А чем так плохи асинхронные фреймворки?
Нет, я понимаю что и на них при желании найдется тест «с резбой». Но синхронные, типа PHP, тут явно не в выигрышной ситуации.
И кстати асинхронные фреймворки не вчера появились. Это только вокруг Ноды крику много. И что странно он частенько подогревается Microsoft-ом. Любопытно в чем тут у них интерес?

kivsiak Oct 4 2011 at 02:50

Плохи? Сами по себе ничем. Я например активно экспериментирую с tornado и gevent (Twisted для мутантов) и результатами доволен, хотя подводные камни тоже встречаются. Плоха шумиха вокруг них развернутая — волшебная палочка которая сделает всем вам хорошо и бесплатно. Собственно статья про то и написана, ну и ощущения от северного js у меня схожие с автором.

govorunov Oct 4 2011 at 03:05

Как показывает практика (моя и не только) — без шума не взлетит. Это лет 10 тому назад можно было написать полезную программу и стать известным за пол года. Сейчас интенсивность фонового шума в интернете такова, что напиши ты хоть серебрянную пулю, если хотя бы ты сам не приложишь все усилия чтобы поднять вокруг своего решения максимально шума — о нем никто и никогда не узнает.
В этом кстати история практически всех успешных решений и новинок последних лет. Они небыли лучшими, и, часто даже небыли первыми. Они просто были самыми шумными. Жаль что так происходит, но такова жизнь…

brainfucker Oct 4 2011 at 12:28

Да бросте Вы, совершенно очевидно, чего автор не понял. Об этом говорит пример с фиббоначи, как бы вы не старались, как бы не параллелили, если у вас одно ядро — Вы можете хоть миллион тредов наплодить, но быстрее всего задача будет решена последовательным выполнением, как в ноде, треды принесут лишь оверхэд, а если ядер несколько — нужно поднимать несколько инстансов ноды. Под неблокирующей архитектурой понимается лишь неблокирование ввода вывода, про CPU никто не говорит.

ivann Oct 4 2011 at 17:30

Быстрее для этого клиента не будет, а для другого — будет, т.к. он не будет ждать в очереди, пока «насильник с фибоначи» отпустит сервер.

gridem Oct 4 2011 at 23:25

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

ivann Oct 4 2011 at 23:50

И я про тоже. Каждый запрос к node должен быть максимально быстрым, чтобы не занимать цикл надолго: сколько новых лайков, есть ли новые сообщение и т.п. Приведенная реализация фибоначи на архитектуру node ложится очень плохо.

Aco Oct 4 2011 at 09:47

> Но синхронные, типа PHP, тут явно не в выигрышной ситуации.

Возможно, но есть асинхронные PHP фреймворки, которые очень порадовали производительностью.

kivsiak Oct 4 2011 at 02:55

Узнал. Хорошо пишет. Мне кажется было бы еще интересно перевести Tornado vs Twisted и I Can't Wait for NoSQL to Die, правда боюсь что тот кто это тут опубликует — без кармы останется быстро.

takkmoil Oct 4 2011 at 03:12

Второй как раз давно хочу перевести, всё руки не доходили. А этот пост совсем за живое задел, потому и.

masterbo Oct 4 2011 at 11:55

ИМХО «I Can't Wait for NoSQL» это набор натяжек в стиле «миллионы домохозяек не могут ошибаться». Вся аргументация строится вокруг того, что реальный бизнес сейчас не строится на NoSQL. Софистика какая-то.

asci Oct 4 2011 at 12:27

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

hf35 Oct 4 2011 at 03:02

Вижу что перевод — но думаю взгяды переводчика в какой то степени отражает)

Могу и с контраргументами

function fibonacci(n) {
if (n < 2)
return 1;
else
return fibonacci(n-2) + fibonacci(n-1);
}

Для ресурсоемких операций — отдельный поток. Но таких в вебе вообще то мало очень. В большинстве случаев мы ждем либо диск, либо ответ от базы данных, либо ответ от другого сервера… Так что фибоначи можно считать в отдельном потоке и выводить всем готовый закэшированный результат. Что намного сложнее сделать в случае CGI — там придется для каждого пользователя считать его отдельно. Или записывать на диск… или в базу… или ещё как.

Про философию UNIX — херня. Нельзя жить вечно с философией прошлого тысячелетия. Это же IT)
Создавать HTTP сервер на ходу — очень удобно. Зато PHP — идеальный пример философии юникс? 100500 функций — каждая из которых делает свою задачу. При этом никакого порядка ни в названиях, ни в порядке переменных, ни в возвращаемых результатах.

Ну а про блядский Javascrpt — кто вас и автора заставляет писать так?

takkmoil Oct 4 2011 at 03:28

Философию вы зря обижаете. Кирпичные дома прочнее и теплее панельных, и соседей не так слышно. А то, что технология древняя… работает же!

К PHP вы тоже совершенно зря прицепились, хотя он действительно вполне себе unix way, хотя бы в части работы в качестве CGI. А названия функций… издержки быстрого роста и тяжкое наследие. Более того, сейчас мне уже кажется, что фразу про Расмуса стоило бы перевести как «вы превзошли даже...»

Давайте говорить о Node, а не тыкать пальцем, что «вон у них тоже всё плохо».

hf35 Oct 4 2011 at 04:19

Зато кирпичные строятся дольше и стоят вроде. )

PHP просто для примера. Философия может и хорошая, но автор почему решил что раз философия хорошая — то иначе и быть — иначе полная херня. Автор притянул за уши все аргументы какие смог. Мог подробно бы обсудить каждый и про бэкенд, фронтэнд сервера и про скорость вычисления Фибоначи в других языках и про запуск из консоли, но во первых мне сообщения можно писать раз в час, во вторых не гуру серверного javascript), а в третьих не вижу смысла.

Мир IT он такой. Все очень любят доказывать что то кому то. Что технология неправильная, что нужно делать так… и т.п. спорить и обсуждать это все бессмысленно — каждый решает для себя сам. Вот человек решил что node хрень — его право. Непонятно почему он пытается других убедить.

Ноду поизвращавшись можно заставить работать как CGI — вот только зачем…

takkmoil Oct 4 2011 at 04:22

Unix way был придуман, чтобы не извращаться.

akzhan Oct 4 2011 at 04:31

Вы правы и неправы одновременно.

Почитайте unicorn.bogomips.org/

node.js вполне unix way.

80x86 Oct 4 2011 at 08:45

Как ваша ссылка доказывает ваше утверждение? Там про нишевой продукт, а не про асинхронную general purpose серебряную пулю.

akzhan Oct 5 2011 at 12:43

Да, ссылку не ту вставил, сорри. Хотел про nginx :)

поясню свою аналогию:

Node построен аналогично nginx, который также использует event-based модель.
Путь Unix подразумевает два варианта — отработку запросов по процессам, или в одном процессе. Использование потоков не поощряется (по сравнению с Windows way).

80x86 Oct 5 2011 at 13:41

Нет, если рассматривать ноуд.джиэс в качестве кирпичика для построения чего-либо. Внутреннеархитектурно — да, на троечку с плюсом.

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

Что инджайникс, что ноуд, — нишевые продукты, «улучшенные и дополненные». С тем отличием друг от друга, что первый — строительный кирпичик-прокси с включаемой функцией имитатора вебсервера, а второй — просто имитатор вебсервера с функцией убийцы эрланга или (с натяжкой) руби.

Я не люблю хейтерство во всех проявлениях (хотя сам на публику, например, иногда этим страдаю), но в данном случае склонен думать, что как нишевое решение ноуд найдёт место под солнцем, как и армию апологетов, в глазах которых классические подходы проектирования программного обеспечения себя дискредитировали в силу столкновения недостаточно опытного человека с реалиями мира. Но признавать ноуд продуктом юникс-пути — увольте, не получается.

masterbo Oct 5 2011 at 14:54

inetd это ведь unix-way? Он же призван встроиться в цепочку от консольной программы до пользователя сети (как pipe, только на уровне сети). nginx выполняет ту же роль. Вы помните почему inetd перестал пользоваться спросом? Он вел себя точно так же как apache — плодил процессы и подгружал программы полными экземплярами. Этот подход оправдывал себя не долго и от него отказались в пользу постоянно висящих в памяти демонов. Разумеется вам никто не мешает поднять старичка из могилы для того, чтобы писать сетевые сервера на shell, но современным требованиям к коммерческим системам это уже не соответствует. То же происходит и с веб-серверами: cgi отмирает из-за низкой эффективности и на его место приходят сервера приложений, управляемые событиями. Node.js просто один из экспериментальных представителей этой эволюции. Выживет он или не пройдет естественный отбор, покажет время, но эволюционный шаг unix, начавшийся с отказа от inetd в любом случае будет сделан. И пока не ясны все особенности приходящей парадигмы, сложно прогнозировать результаты этого эксперимента. А автор, в силу юношеской категоричности, ищет грань между черным и белым в сером мире, цепляясь за свое прошлое и навязывая его восприимчивому читателю.

80x86 Oct 5 2011 at 15:01

Я ещё раз напишу. Тред начался с того, что ноуд назвали продуктом юникс-пути. Я как можно проще изложил, почему я не считаю это корректным.

С вами целиком согласен. Смысл эволюции в многообразии форм и все эти формы имеют право на существование.

masterbo Oct 5 2011 at 15:20

Может мы с вами по-разному понимаем одни и те же выражения, но архитектура event-driven приложений это на мой взгляд именно продукт пути, который проходит unix. С другой стороны unix-way, как понятие, означает не эволюцию, а идеологию и в этом контексте node.js не соответствует букве, хотя и пропитана духом unix-way.

80x86 Oct 5 2011 at 15:23

Я специально отбил параграфы в своём предыдущем респонзе для разделения мыслей.

Да, не UNIX-way.

Да, event-driven и message-driven живут и у них есть будущее.

masterbo Oct 5 2011 at 15:38

Я специально отбил параграфы в своём предыдущем респонзе для разделения мыслей.

Я отвечал на первый :)

Да, не UNIX-way.

С буквой всё понятно, но даже духа не признаете?

80x86 Oct 5 2011 at 15:45

Дух свободы и нигилизма? :) Шутка.

Понятие этого духа у каждого своё и оно похоже на понятие демократии.

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

masterbo Oct 5 2011 at 15:48

Спасибо. Исчерпывающе. :)

josser Oct 4 2011 at 11:59

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

akzhan Oct 4 2011 at 04:29

Вы не вполне правы. Отдельный поток тут выгоден не всегда.

Более кошерно каждую следующую итерацию уводить в nextTick.

UFO just landed and posted this here

seriyPS Oct 4 2011 at 22:07

Да не, нормально будет работать — даже статья на хабре про этот метод была habrahabr.ru/blogs/nodejs/112742/. Но это какая-то «добровольная многозадачность» получается. Программист берет на себя задачи планировщика.

80x86 Oct 4 2011 at 08:33

Разница между node.js и unix way в том, что node.js разрабатывают и используют восторженные энтузиасты, а unix way — продукт мощного инженерного подхода. Как показывает практика, 40 лет он летал, этот unix way и будет летать дальше. Быстро, эффективно и масштабируемо.

Запомните — разработчики являются ресурсом, а не самоцелью. Синтаксический сахар и лень рождают чудовищ.

UFO just landed and posted this here

80x86 Oct 4 2011 at 15:40

Наращиваемо как по горизонтали, так и в архитектурном плане, вверх.

akzhan Oct 5 2011 at 12:46

очень правильное высказывание, но с одним минусом. вы просто не пробовали интегрировать Node именно согласно Unix way.

Воспринимайте Node как великолепный агрегатор.

80x86 Oct 5 2011 at 13:50

Как использовать ноуд в качестве конечного решения — представляю, а как можно интегрировать согласно юникс-пути — неа, в упор не представляю.

shoorick Oct 4 2011 at 13:27

Пхп — это пример не юниксовой философии, а образцово-показательного бардака.

greebn9k Aug 22 2019 at 20:33

-30! За вполне сильные контраргументы в 2011! Как там в 2011?

takkmoil Aug 23 2019 at 10:27

Всё-таки это мой самый удачный перевод, до сих пор волны расходятся :D

Zibx Oct 4 2011 at 09:14

Вот отличный контраргумент. V8 долизан до такого состояния что генерит адекватный машинный код в реалтайме. Потому по скорости там всё чудесно. Другое дело что надо им научиться напрыгивать на все ядра процессора.

dmitriid Oct 4 2011 at 13:59

Если у них stop-the world GC и отсутсвие нативной поддержки многопоточности, то натягивай-не натягивай, смысла не будет

smartov Oct 4 2011 at 09:26

Переводите. Тем более что у вас отлично выходит.

Que Oct 4 2011 at 10:59

>Ну тогда поперевожу ещё

На самом деле не стóит.

takkmoil Oct 4 2011 at 10:59

Для вас — не буду.

Que Oct 4 2011 at 11:05

Да не только для меня.

Действительно, поторопились вы с публикацией такого сырого перевода. Ужасные кальки с английского.

takkmoil Oct 4 2011 at 11:08

Если есть возможность — опишите, пожалуйста, в личку, что конкретно резануло. Расти есть куда, я не спорю, первый же перевод.

Que Oct 4 2011 at 11:53

Отправил несколько замечаний =)

dikarik Oct 4 2011 at 19:46

Наоборот — эти самые кальки отлично создают атмосферу

Que Oct 4 2011 at 20:59

Кальки можно использовать как приём, безусловно. Но сочный слог Теда стоит передавать таким же сочными оборотами русского языка =)

adamantine Oct 4 2011 at 12:22

А Вы знакомы с Тедом Мосби?

abcfilm.tv/img_kadr/58/02_04_6.jpg

takkmoil Oct 4 2011 at 12:27

Я, бывает, смотрю про него сериал. Забавный парень, скажу я вам, но сюжет вытягивает один Барни уже который сезон.

deniszh Oct 4 2011 at 15:23

Уже имхо к сожалению и не вытягивает… (пичаль)

gradmax Oct 17 2011 at 20:23

проверено на ноде, си, пхп:
нода: 5 секунд (но ёлки...331 миллион итераций… хз откуда такой алгоритм))))
си: 1 секунда
пхп: 1 минута 35 секунд (для одарённых это 95 секунд))))

исходники на СИ:

long fibonacci(int n) {

if (n < 2)

return 1;

else

{ 

return fibonacci(n-2) + fibonacci(n-1);

}

}

int main() { 

fibonacci(40);

}

исходники на ПХП:

<?php

$i = 0;

function fibonacci($n) {

global $i;

if ($n < 2)

return 1;

else { $i += 2;

return fibonacci($n-2) + fibonacci($n-1);

}

}

echo fibonacci(40);

echo $i;

?>

kekekeks Oct 4 2011 at 02:05

>>Ещё пади PHP считаете идеалом?
>>вы будете гореть в аду

Традиции Хабра: разговор с ~~копипастой~~переводом.

limitium Oct 4 2011 at 20:54

Между тем тот же код в
php: 2m 31s
java: 0.891s
javascrip: 2.45s
ruby: 23.2s
as3: 2.2s

virtustilus Apr 2 2016 at 20:19

Между тем через много лет :)
python3: 38.629s
php7: 11.693s
node5: 1.893s
java8: 0.546s
неприятно удивил питон, думал он будет наравне с php по математике или даже быстрее

Illorian Oct 10 2011 at 20:10

-80… это жестко

Infernal Oct 4 2011 at 01:56

Выговорился, полегчало?

takkmoil Oct 4 2011 at 01:57

ПЕРЕВОД

ivv Oct 4 2011 at 02:03

перевод лучше оформлять как перевод, тогда будет намного меньше вопросов

ivv Oct 4 2011 at 02:04

короче гон :) иконка перевода внутри топика не показывается а в списке топиков да

takkmoil Oct 4 2011 at 02:06

Что я делаю не так?

ivv Oct 4 2011 at 02:07

все так, просто раньше иконка перевода по-моему была и когда просматриваешь страницу топика а не только в списке

lolmaus Oct 4 2011 at 09:38

Да по слогу очевидно же, что перевод. :)

takkmoil Oct 4 2011 at 09:46

Ну буду стараться.

lolmaus Oct 4 2011 at 09:48

Перевод очень хороший, кстати. Легко читается, понимается без напряжения мозга.

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

takkmoil Oct 4 2011 at 10:53

Спасибо, наконец-то пригодилось высшее филологическое :)

HEm Feb 13 2012 at 11:09

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

Honeyman Oct 4 2011 at 06:45

Жаль, что, благодаря интерфейсу Хабрахабра, понять, что это перевод, теперь можно только дочитав до конца и увидев мааасенькую ссылочку на оригинального автора:

Ну, или где-нибудь на третьем абзаце осознать, что это перевод, по не характерным для русского языка выражениям (ну, например, вряд ли по-русски кто-нибудь сказал бы «Это утверждение заманчиво, ободряюще и полностью, блядь, неверно.» вместо хотя бы «Это утверждение заманчиво, ободряюще и нихуя не верно.»).

maxvipon Oct 4 2011 at 07:43

Вот-вот, только хотел написать, что практически все переводы тут спокойно узнаю по нехарактерным оборотам (:

andoriyu Oct 4 2011 at 10:31

Вот вот. Хабр в очередной раз показал свою стадность. Стыдно должно быть.

maxvipon Oct 4 2011 at 10:52

Стыдно за что? За то что люди мыслят похожим образом? Или за то что плодят бесполезные комментарии?

andoriyu Oct 4 2011 at 13:47

За то что люди мыслят похожим образом.

maxvipon Oct 4 2011 at 14:37

О боже… Пойду стыдиться.

IDMan Oct 4 2011 at 20:00

Количество всевозможных точек зрения много меньше людей. Так что мыслить одинаково обречены даже те, кто на словах стыдится этого.

UFO just landed and posted this here

dobriykot Oct 4 2011 at 17:35

Ага, и к концу такой облом, что перевочика не польешь говном за спорную статью)

Kicker Oct 4 2011 at 01:59

И не в лом же было переводить такое…

vics001 Oct 4 2011 at 02:02

Уберите мат! Может в оригинале и сойдет, но не в русском.

takkmoil Oct 4 2011 at 02:07

Таков уж Тед. Иначе как «Криминальное чтиво» в переводе НТВ смотреть.

andoriyu Oct 4 2011 at 11:45

> Таков уж Тед.

Всегда поражали люди которые так говорят. Вы знакомы с Ted Dziuba лично? Поэтому называете его Ted? Или вы чувствует СВЯЗЬ между вами когда читаете его блог? Или это у вас так в Краснодаре принято? Саша, что на это скажешь?

takkmoil Oct 4 2011 at 11:54

Вы правы, Андрей, правильнее было бы сказать «таков уж стиль изложения Теда». Нет, я не знаю Теда лично, но давненько почитываю его опусы, да и вообще он мне интересен как личность. Я не вижу ничего страшного в том, чтобы называть людей по имени, ведь оно затем и даётся, разве нет? Более того, очень не люблю русскую традицию обращаться по имени-отчеству, мне кажется, «вы» вместо «ты», на которое мы с вами не переходили, вполне достаточно.

arkamax Oct 4 2011 at 12:34

И кстати, в той культуре, откуда родом Тед (а также в родственных) люди обычно представляются по имени (причем так делает кто угодно, вплоть до нобелевских лауреатов), и предпочитают, чтобы их так называли. Автору спасибо за перевод.

andoriyu Oct 5 2011 at 02:26

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

UFO just landed and posted this here

anycolor Oct 4 2011 at 02:51

из песни слов не выкинешь.

utf9 Oct 4 2011 at 04:06

E-mail, принимающий жалобы от персон, оскорбленных нецензурной лексикой:
thisisnotarealemailyouasshole@thisisnotarealemailserver.com

TheBits Oct 4 2011 at 02:20

Время ответа — 5 секунд.

Тед посчитал время запуска программы curl, её работы и завершения. Типичная ошибка разных тестировщиков скорости.

Числа в V8 (как и в PHP) представляются в виде машинных чисел в процессоре. По-этому математика там будет быстрой. Тест с числами Фибоначчи выбран не удачно что бы показывать тормоза. :)

takkmoil Oct 4 2011 at 02:21

Что насчёт результатов ab?

TheBits Oct 4 2011 at 02:28

Правдоподобны.

philpirj Oct 4 2011 at 03:47

Повеселили, спасибо.

$ time curl localhost:3000



real 0m0.051s

user 0m0.012s

sys 0m0.008s

josser Oct 4 2011 at 12:05

Очевидно что у вас разное желехо и результаты разные. Это не в защиту автора, а к вопросу о «правильости» тестирования.

homm Oct 5 2011 at 21:54

На 3 порядка, думаете?

weirdan Oct 4 2011 at 04:41

Тед посчитал время запуска программы curl, её работы и завершения. Типичная ошибка разных тестировщиков скорости.

По результатам четко видно, что большую часть времени курл провел в заблокированном состоянии (читай: ждал ответа от сервера).

BVadim Oct 4 2011 at 05:01

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

weirdan Oct 4 2011 at 05:19

Гневная статья? Где вы там гнев усмотрели?

BVadim Oct 4 2011 at 05:28

Если перечислять всё можно скопипастить почти всю статью.
К примеру это:

Node.js — это опухоль на программистском сообществе

и это

Возможно, худшее, что можно сделать с серверным фреймворком, — написать его на JavaScript.

и это

Node.js — неприятное ПО

Ну и весь мат.

weirdan Oct 4 2011 at 05:35

Как по мне — обычная гипербола. Да и мат из разряда «мы им не ругаемся, мы на нем разговариваем».

dmitriid Oct 4 2011 at 14:01

> автор не понимает как работает node.js или специально вводит в заблуждение тех, кто ещё не разобрался.

node.js утверждет, что scalable решения будут писать именно такие неразобравшиеся ;)

masterbo Oct 4 2011 at 14:18

Есть лозунги и есть реальность. Как только дело доходит до серьезных денег, писать будут те, кто разобрался. А что разбираться легче, так за это автору спасибо.

dmitriid Oct 4 2011 at 14:19

Между «меньше-чем-эксперты» и «серьезные деньги» — пропасть. Не говоря уже о том, что благодаря EC2 и Azure можно начинать экспериментировать с масштабируемостью и без особых денег и/или знаний.

masterbo Oct 5 2011 at 04:52

Между «меньше-чем-эксперты» и «серьезные деньги» — пропасть.

Вас всерьез беспокоит чем увлекаются другие? Вы сокрушаетесь, что кто-то сделает не достаточно хорошо (по вашим меркам) только потому, что пошел на поводу у лукавой рекламы? Или вам никто не рассказал, что это плохо — негодовать по поводу чужих предпочтений, не совпадающих с вашими? Доводы автора о не правдивости рекламы node.js несостоятельны — порог вхождения действительно ниже и существует круг задач, где эта технология имеет свои преимущества. А то, что Тэд искал в ней универсальность викторинокса — личные проблемы Тэда и других страдающих психозом перфекционизма. Не существует самого лучшего языка или архитектуры, есть лишь удачные для определенного круга задач.

Не говоря уже о том, что благодаря EC2 и Azure можно начинать экспериментировать с масштабируемостью и без особых денег и/или знаний.

Боюсь вы введены в заблуждение. Приступая к использованию этих платформ начинать экспериментировать с масштабиемостью уже поздно — на момент запуска проекта на этих сервисах надо уже четко осознавать что и для чего ты делаешь, чтобы избегать блокировок уровня архитектуры кластера. А при этом возникают проблемы, в сравнении с которыми блокировка потока node.js покажется цветочками. (Ну запустил для вашей задачи EC2 копию вашего сервера на соседнем ip, как вы собираетесь синхронизировать копии данных? Заблокируете копии приложения обращением к одной базе данных с разных серверов? Включите зеркальную репликацию данных между серверами, создав затор обменом между копиями СУБД?). Нет, тут уже не отделаешься простыми решениями, за которые так ратует автор поста. Тут придется разбираться со всякими Hadoop и/или RabbitMQ, которые бесконечно далеки от любимого Тэдом CGI-подхода (распараллеливания процессов полными экземплярами). Вот так поэкспериментируешь с EC2 и дойдет в чем главные преимущества однопоточной архитектуры для масштабирования. И перестанете слушать всяких троллей. Может на node.js не остановитесь, но уж чем Tornado или OTP лучше любимого Тэдом django в нагруженных проектах, усвоите на зубок.

ttim Oct 4 2011 at 04:54

Как будто 1000 число фиббоначи хоть на каком-нибудь языке будет быстро работать =)
Так что пример нормальный.

putnik Oct 4 2011 at 23:41

Да на любом оно будет работать, если не через одно место писать. Тысяча операций сложения — пшик.
Но, если писать рекурсивную функцию, да ещё такую, которая для подсчёта числа высчитывает два предыдущих (а для тех ещё два, …), то конечно, тут не поспоришь.

UFO just landed and posted this here

masterbo Oct 5 2011 at 04:59

Если загнать ОС в глубокий SWAP, то может и больше. Но в данном случае конечно большая часть процессорного времени была занята тяжелой рекурсивной функцией.

qrazydraqon Oct 4 2011 at 02:26

Текст из разряда «я умный, потому что бородатые дяди умные, а вы тупые, потому что вы тупые». Где умное-то в этом тексте?

UFO just landed and posted this here

yaroslavm Oct 4 2011 at 03:14

1. github.com/glenjamin/node-fib — комментарий к оригинальному посту (вернее, к ссылке на него на Hacker News).

А HN, кстати, давно утвердился в качестве ведущей помойки англоязычного программерского сообщества. И ведь кому то было не лень переводить это все, с матершиной, и выкладывать на Хабр. Фантастика.

2. Дискуссии в постах вида «X — говно, а автор Y — тупица» быть никакой не может. Кому что нравится, тот и использует: Node.js, Erlang/OTP, Scala — какая разница? Райан из ничего сделал ведущий JS рантайм, и получает за это тонны навоза на голову каждую неделю. Любой, кто делал FOSS проект который использует хотя бы пара сотен человек, знает, каково это — когда куча трепачей критикуют (а часто и оскорбляют) тебя за то, что ты что-то сделал, в отличие от них.

takkmoil Oct 4 2011 at 03:47

1. Я читаю лично Теда, о HN узнал от вас только что. Мне было не лень переводить пост, который меня задел. В комментарии на гитхабе, в секции «Why?» примерно моя позиция описана.

2. Вообще, я надеялся, что придут гуру серверного JavaScript и расскажут подробно, в чём Тед ошибается. Пока аргументов было немного, а из исходника по вашей ссылке я понял, что его писал не-менее-чем-эксперт. Тед же подошёл с позиции именно такой, и успешно доказал, что кухарка сервера писать всё ещё не может.

Sannis Oct 4 2011 at 03:52

2. Это было и так понятно.

aspect Oct 4 2011 at 07:07

«сначала добейся»

UFO just landed and posted this here

crea7or Oct 5 2011 at 16:02

Да, слог просто чудесный. Я даже не догадывался что это перевод.

corpix Oct 4 2011 at 03:19

А мне вот наоборот очень даже нравится node.js
По поводу блокировок:
Блокируемыми являются потоки, но не сам процесс. Читая перевод возникло ощущение того, что Тэд считает, что блокировка потока означает блокирование процесса.

takkmoil Oct 4 2011 at 03:31

Не считает, и даже упоминает, к каким проблемам может привести бесконечное рожание потоков.

corpix Oct 4 2011 at 03:37

Да, всё верно, я видимо не так понял

BVadim Oct 4 2011 at 03:48

А Ferrari SA Aperta очень не удобно ездить на дачу. Ferrari говно?
Статья — совершенно однобокий взгляд на node.js. Обсуждать даже смысла нет. О том как именно работает event loop и что делать со сложными математическими вычислениями написана тонна статей. Если кто-то использует node.js не понимая как он, в действительности, работает и надеясь на магическое слово «асинхронно» то это его проблема, а не Райана.

takkmoil Oct 4 2011 at 04:19

Так ведь Райан сам призывает забыть обо всём и просто писать быстрые приложения, не заботясь ни о чём. Собственно, маркетинг в этой статье, по большей части, и высмеивается, ну а про unix way Тэд просто не мог не упомянуть.

BVadim Oct 4 2011 at 04:36

Я не думаю, что Райан словами «less-than-expert» имеет ввиду студентов которые только-только узнали о node.js и решили его использовать для своего супер-стартапа. Мне кажется, что для разработчика такого уровня «less-than-expert» это тот, кто сам не может создать такой же node.js.

BVadim Oct 4 2011 at 04:07

Серверный JS сильно отличается от клиентского, хотя заманчиво на него похож. Многие начинают использовать node.js основываясь на своих знаниях и опыту написания клиентского JS. Но почти сразу сталкиваются с проблемами, которые браузер им «прощает». Большая часть JS-скриптов на клиенте работает 1 раз при генерации страницы или основываясь на действиях пользователя (клики, ввод данных и т.п.). Речь не идёт о сложных браузерных «долго живущих» приложениях которые. Так вот. В простых клиентских скриптах не обязательно заботиться об очистке памяти, о сильно скрученных замыканиях и т.п. Т.к. страница живёт относительно не долго (и скрипт вместе с ней) то такие «косяки» не видны. И кажется что JS очень простой. Но когда такой же стиль написания применяется в серверном JS — все недочёты быстро дадут о себе знать. И в этом месте начинающие node.js разработчики делятся на 2 категории. Первые идут разбираться почему их приложение работает медленно/жрёт память/падает/грузит процессор на 100%, осознают принципы и пишут нормально. А вторые идут на форумы и льют тонны говна на Райена, JS и «всех этих фанатиков».
Мне кажется что это уляжется только когда все осознают что JS это не «почти как на пэхэпэ но проще и есть свой сервер», а довольно сложный язык программирования, явно сложнее PHP (PHP тоже многое «прощает» из за того что скрипт живёт не долго и синхронно писать легче), который требует глубокого понимания принципов работы, принципов асинхронности и т.д.
Серверный JS не для домохозяек.

takkmoil Oct 4 2011 at 04:12

… но от маркетинга никуда не деться.

akzhan Oct 4 2011 at 04:20

Все лозунги Node.JS про простоту разработки нужно отсчитывать от уровня самого Райана :)

BVadim Oct 4 2011 at 04:32

Если бы node.js продали с такими обещаниями, то можно было бы подать на Райана в суд, но он бесплатен и распространяется как есть. А так, это просто краткое описание принципов работы node.js. Любой адекватный разработчик понимает что «nothing blocks» это не волшебство, а «почти ничего не блокируется». В любом случае — лить говно на чей-либо труд таких объёмов, основываясь только на нескольких строчках главной страницы, приводя примеры, которые заведомо будут тормозить — это обычный троллинг. Таких примеров можно привести миллион: айфоном плохо забивать гвозди, молотком плохо звонить.
Райану — огромное спаисбо за работу.
Горе-разоблачителям — вкусной кормёшки.

norguhtar Oct 4 2011 at 08:14

А теперь вопрос зачем на этом писать? Для io-bound как пишут ниже? Для этого можно спокойно взять java.

UFO just landed and posted this here

norguhtar Oct 4 2011 at 09:57

Тут только что написали, что server side javaScript отличается от client side. Что по сути выливается в разные парадигмы программирования.

UFO just landed and posted this here

dmitriid Oct 4 2011 at 14:03

> объекты не нужно сериализовать/десериализовать

Нужно. Потому что JSON-JSON'ом, но eval при этом никуда не девается

Mithgol Dec 17 2011 at 10:26

Строго говоря, никуда не девается синтаксический анализ; но eval для него не обязательно нужен.

Во-первых, есть скрипты наподобие json_sans_eval и JSON-js, способные невозбранно анализировать JSON, не прибегая к eval.

Во-вторых, даже и они не требуются, потому что в современных браузерах есть быстрые методы JSON.parse и JSON.stringify — есть они, понятное дело, и в движке Node.js, основанном на V8.

asci Oct 4 2011 at 10:57

ну мне например, кажется заманчивым, что мне можно одни и те же алгоритмы проверок, как на клиенте, так и на сервере использовать для небольшой игрушки на html5, исходя из принципа «сначала сделать клиент и протестить клиент, а потом перенести часть критичного кода на сервер»

norguhtar Oct 4 2011 at 11:05

У меня вопрос. А с чего оно будет работать там «быстрее» чем в клиенте? К примеру при использовании Chromium?

asci Oct 4 2011 at 11:08

«критичные» не в плане скорости, конечно же) защита от хаков

BVadim Oct 4 2011 at 09:23

Тоже самое можно спросить, а зачем писать на Java, если можно на node.js? Всё зависит от конкретной задачи, конкретного разработчика, его опыта и привычек. Плохую программу и хорошую программу можно написать на любом языке.

norguhtar Oct 4 2011 at 09:58

Хотя бы по той причине, что не надо ломать себе мозг той самой серверной реализацией.

UFO just landed and posted this here

norguhtar Oct 4 2011 at 12:57

Одно дело когда у вас разные языки. А другое дело когда язык один, а подходы разные. И вы на дню по несколько раз переключаетесь туда сюда.

dikarik Oct 4 2011 at 19:53

Джаваскрипт динамический и слабо типизированный. Он по определению будет медленнее джавы. Насколько — это уже зависит от паттернов использования и изощрённости движка.

tyro Oct 4 2011 at 11:22

По моему язык здесь не причем, а виновата асинхронная модель программирования. На JavaScript можно и удобно писать код в синхронном стиле используя RingoJS или мой проект Common Node. Если интересно, то вот моя презентация с RejectJS в Берлине на прошлой неделе.

akzhan Oct 4 2011 at 04:10

Спасибо за перевод, очень экспрессивно. Сам думал перевести, но вчитался, и понял, что не буду.

По уму — автор неправ. Гораздо интереснее и точнее вот это: habrahabr.ru/blogs/nodejs/127696/

UFO just landed and posted this here

akzhan Oct 5 2011 at 13:23

Да, аналогично unicorn или nginx, есть и такая магия.

Для ростоты есть библиотеки типа github.com/kriszyp/multi-node

egorinsk Oct 4 2011 at 06:24

Какой-то бессмысленный текст — автор показал, что рассчет числа Фибоначи займет 5 секунд? А что, если он напишет его рассчет и запустит в CGI-сервере, он отработает быстрее?

Есть определенная ниша, где применение событийных фреймфорков здорово помогает (типичный пример — тысячи висящих соединений с иногда происходящими на них событиями). Нахваливаемый автором юникс-вейный CGI (это ж надо было додуматься, на каждое входящее соединение стартовать по процессу!!!) в такой ситуации съест все ресурсы сервера на форк процессов. Ну вы знаете, это то же, что бывает с сервером, если после установки Апача не понизить MaxChild (который там по дефолту то ли в 200, то ли в 300 установлен). Лучше ноды тут только C++/D и подобные языки.

Так что статья ни о чем. Если вы пишете скрипты, которые работают по 5 секунд с полной загрузкой CPU, вам ничего уже не поможет.

powerman Oct 4 2011 at 11:33

В CGI сервере, по крайней мере, этот расчёт не заблокирует accept() входящих соединений, позволит загрузить все ядра CPU параллельными запросами этого расчёта, и не помешает параллельно с медленной обработкой этих запросов быстро обрабатывать другие запросы (как CGIшные так и на статический контент).

И да, форк это тоже не решение в современных условиях, здесь я с Вами полностью согласен.

На мой взгляд суть статьи в том, что:

— Совмещать веб-сервер и «неблокирующие» обработчики запросов в одной нити это плохая идея.
— Разработка неблокирующих серверных приложений это сложная задача для экспертов, а не простая для менее-чем-экспертов, как это рекламируется.
— JavaScript не самый подходящий язык для сервера.

И лично я со всем этим полностью согласен (хотя последний пункт аргументировал бы не примером с undefined (синтаксис в языке не главное), а тем, что толпы существующих JavaScript-разработчиков привыкли писать клиентский JavaScript, а на сервере надо писать совершенно иначе — что превращает «плюс» использования уже известного языка в «минус» иллюзии что вы знаете как писать на этом языке на сервере).

Leeb Oct 4 2011 at 11:53

Лучше ноды тут Erlang, Scala, Haskell, а потом уже все остальное.

vlm Oct 4 2011 at 15:49

Erlang ещё быстрее чем Node.JS считает фибоначчи: lionet.livejournal.com/95346.html

Evengard Oct 4 2011 at 15:51

Вот многие нахваливают Erlang — особенно в сравнении с Node.JS. Щас почитал немного и пока не понял — в чём его прелесть?

Leeb Oct 4 2011 at 16:08

В концепции. Можно завести по одному потоку на каждое из нескольких десятков тысяч подключений и не опупеть.

vlm Oct 4 2011 at 16:13

1. несколько ортогональных инструментов обработки ошибок (hot code reload, try/catch, linked processes, supervisors)
2. горячая замена кода без остановки приложения. работа 24/7/365 без остановки для апгрейда.
3. горячий дебаг без пауз того, что дебажится
4. отсутствие разделяемой памяти — изоляция процессов друг от друга
5. возможность породить десятки и сотни тысяч независимых процессов, выполняющихся параллельно друг с другом и не блокирующих друг друга
6. неизменяемые структуры данных — способ исключить целые классы ошибок в коде
7. мощные библиотеки работы с асинхронными процессами — в бою уже пару десятков лет.
8. делать код-ревью на Erlang проще, чем на императивных языках типа PHP, Perl, etc: lionet.info/pdf/2010-lev-walkin-erlang-experience.pdf
9. по сравнению с Node.JS — код выглядит как код, а не как лапша:

Step(
  function readSelf() {
    fs.readFile(__filename, this);
  },
  function capitalize(err, text) {
    if (err) throw err;
    return text.toUpperCase();
  },
  function showIt(err, newText) {
    if (err) throw err;
    console.log(newText);
  }
);

Эрланг:

  {ok, Data} = file:read_file(Filename),
  Text = string:to_upper(binary_to_list(Data)),
  error_logger:info_msg("~s", [Text]).

www.slideshare.net/rit2010/max-lapshin-erlyvideo-v2
lionet.info/pdf/2010-lev-walkin-erlang-experience.pdf
lionet.livejournal.com/tag/erlang

Evengard Oct 4 2011 at 16:46

Кажется, начинаю понимать прелесть. Правда, с другой стороны смущает, что, например, в списках вроде как нельзя обратиться к, скажем, второму элементу списка, или ещё что-то вроде этого… А так же иммутабельность.

Leeb Oct 4 2011 at 17:17

> в списках вроде как нельзя обратиться к, скажем, второму элементу списка
lists:nth([1,2,3,4,5], 2)

> А так же иммутабельность
К ней быстро привыкаешь. Да и обращаться ко второму элементу списка даже и не вспомню, когда приходилось. И иммутабельность, и набор типов данных приводят к другим алгоритмам работы с ними.

Evengard Oct 4 2011 at 17:51

Догадываюсь :) Не очень сложно переучиваться то? Что хорошего посоветуете почитать?

Leeb Oct 4 2011 at 17:58

Несложно. По наблюдениям некоторых товарищей, продакшн код вполне получается писать через 2 недели изучения. Из почитать, можно начать с Learn You Some Erlang for Great Good!. Лично я учил по Erlang Programming. Ну а потом уже можно и OTP in Action.

dikarik Oct 4 2011 at 20:03

Причём " Learn You Some Erlang for Great Good!" стоит читать ровно до того момента, как эрланг перестанет казаться совсем уж инопланетным. Потом «Erlang and OTP in Action» гораздо лучше — кроме языка (который, в сущности, прост и, честно говоря, мог бы быть заменён на другой язык без особых потерь) показывается самое важное — использование инфраструктуры OTP, которая и даёт основные преимущества.

Ещё раз подчеркну: суть — не в эрланге как таковом, и его изучение — это только верзушка айсберга. Суть в OTP.

Evengard Oct 4 2011 at 22:03

Спасибо за рекомендации! «Инопланетным» мне Эрланг перестал казаться быстро, но хотя бы пройдусь по первому ресурсу)

nuit Oct 4 2011 at 18:28

Pragmatic Programmers, Erlang in Practice

UFO just landed and posted this here

Leeb Oct 4 2011 at 18:16

Это прям как ядерной ракетой банку тушенки открывать :)

UFO just landed and posted this here

dikarik Oct 4 2011 at 20:00

Про язык вам уже выше сказали, но основная фишка в другом — это предельно тщательно продуманная платформа, прошедшая проверку огнём, водой и медными трубами. Практически на любую архитектурную проблему, с которой вы столкнётесь, вы найдёте хорошее идиоматичное решение в рамках фреймворка, без прикручивания сторонних костылей — от конфигурирования и деплоймента до обновления. Сравнить это можно разве что с Java EE — больше я решений подобного уровня не видел. Но в OTP всё это делается куда как понятнее и читабельнее.

QtRoS Oct 4 2011 at 06:26

> Это утверждение заманчиво, ободряюще и полностью, блядь, неверно.

Я бы за это предложение Вам руку пожал!

UFO just landed and posted this here

takkmoil Oct 4 2011 at 09:15

Это чистый троллинг в стиле Теда Дзюбы. Он специально пишет так, чтобы те, кто мог оскорбиться, оскорбились и уронили планку. Статью перевёл оттого, что боль в жопе никогда не мешала мне трезво мыслить. Аргументация в статье есть, и, повторюсь, основной наезд в ней — на маркетинг в стиле «кухарка сможет писать быстрые сервера, потому что ничего не блокируется». Этот подход в корне неверен, и мы уже видели, к чему он приводит, на примере PHP, только там похожий тезис повторяли фанатики, а здесь — сам создатель инструмента. А если он так утверждает, он либо нагло лжёт с целью заработать медаль «за создание лекарства от всех болезней», либо недальновиден и не понимает, к чему могут привести подобные заявления. Это мы, опять же, видели на примере PHP, в который очень быстро влилось множество кухарок, а через год миллионы людей начали его хаять за то, что на нём можно писать говнокод.

Пожалуйста, покажите, какие именно ответы я проигнорировал: у Теда комментариев на сайте нет, здесь по делу минимум. Пойду почитаю HN, на который мне показали перед сном.

UFO just landed and posted this here

masterbo Oct 4 2011 at 12:41

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

— Ах вы обманули нас словами «неспециалисты смогут писать». Нет такой области компьютерной инженерии, где всё пишут специалисты. Послушайте что говорят бухгалтера про разработчиков желтой программы, про банк-клиенты. Посмотрите на множество убожеских сайтов. Ужас, правда? То же самое творится у строителей, педагогов, медиков… Один специалист на 50 ничтожеств. Таков наш мир и наивно полагать, что загнобив одного выскочку за то, что он пообещал слишком красиво, вы измените мир к лучшему. Перфекционизм — болезнь и вам с Тэдом не плохо бы от нее вылечиться перед тем, как писать для публики.

— Блокирование потока это якобы проблема неблокирующего фреймворка. Это, блядь, проблема процессора, который исполняет одну программу одним потоком. Это не ошибка проектирования, а логическая основа программирования. Наезжать а это всё равно, что критиковать ускорение свободного падения. Не умеешь обходить блокировки — пиши под cgi, пусть эта проблема переляжет на плечи админа.

— Идеология UNIX не имеет к написанию веб-приложения никакого отношения. CGI давно доказал свою несостоятельность для серьезных проектов. Использовать Nginx в качестве http-сервера никто не мешает. И причитать по этому поводу совершенно не конструктивно. Чистый троллинг на пустом месте.

proxor Oct 4 2011 at 07:49

Tornado умеет асинхронно отдавать данные, не блокируя других клиентов. Так что проблемы с Фибоначчи там просто нет. Думаю, что и в Node.js сделать такое несложно, если уже не сделано. Статья интересная, но многовато ругательств.

orcy Oct 4 2011 at 09:16

И что же интересного в статье? Срыв покровов что фибончаи заблокируют поток? Как будто пацаны этого и так не знают. Что кому-то не нравится JavaScript? Что какой-то чувак не будет писать на Node.JS? Хоть бы одну интересную проблему обозначили, а то выглядит так как будто автор прочитал статью на википедии перед сном и пошел срывать покровы. Даже пассаж про веб сервера странный, как будто nginx не цепляют повсеместно перед той или иной динамикой.

proxor Oct 4 2011 at 09:19

То, что даёт определённую пищу для размышлений. Любая статья, отрицательно ориентированная к некоему продукту, какой бы однобокой и лживой ни была — всегда полезна.

masterbo Oct 4 2011 at 12:55

Не любая.

takkmoil Oct 4 2011 at 09:21

Чтобы вменяемо отдавать статику, реврайтить URL и «прочие фантастические штуки», Node.js необходим nginx или что-то подобное. Другое дело, что Node не предназначен для писания CMS, а менее-чем-эксперты, которых своею политикой притянул Райан, пытаются совать его куда ни попадя, не задумываясь, ведь им же сказали, что это идеальное решение.

proxor Oct 4 2011 at 09:22

Ровно такая же ситуация с noSQL, чему вы удивляетесь.

orcy Oct 4 2011 at 09:40

Я не слишком большой спец во всех технологиях, но если мы пишем что-нибудь высоконагруженное на python, ruby, java нам не нужен nginx для статики?

takkmoil Oct 4 2011 at 09:48

FastCGI.

orcy Oct 4 2011 at 10:09

То есть перед python, ruby, java нам нужен FastCGI сервер вроде nginx, как и для Node.js?

takkmoil Oct 4 2011 at 10:17

Вы таки не поверите, перед perl, php, python (за остальные говорить не буду) нужен веб-сервер! Fast он будет или просто CGI — неважно, интерпретатор не берёт на себя работу веб-сервера.

orcy Oct 4 2011 at 10:48

Мне просто непонятно почему веб-сервер перед PHP — это хорошо, а веб сервер перед node — это плохо (разница только в интерфейсе HTTP/CGI). Другое дело что для своих задач веб сервер node можно использовать как standalone с высокой степенью крутости (ну и да, на CMS-ках смысла может и не быть).

UFO just landed and posted this here

masterbo Oct 4 2011 at 13:10

И это не мешало появлению HTTP-серверов написанных на perl и python. Те же разработчики tornado хоть и пишут, что на продакшне у них стоит nginx, внедрили в свой фреймворк и настоящий http-сервер. Я не вижу в этом разнообразии ничего плохого, хотя nginx ставлю и перед apache тоже.

takkmoil Oct 4 2011 at 15:22

Ну и на PHP тоже вебсерверы есть. Но разве не лучше отдать эту задачу «настоящему» серверу?

masterbo Oct 4 2011 at 16:02

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

masterbo Oct 4 2011 at 13:07

Другое дело, что Node не предназначен для писания CMS, а менее-чем-эксперты, которых своею политикой притянул Райан, пытаются совать его куда ни попадя, не задумываясь, ведь им же сказали, что это идеальное решение.

По той же логике Nikon виноват, что большинство хозяев цифрозеркалок снимает в режиме Auto. Как посмел Nikon сказать, что фотографировать может быть проще, чем в начале века? Калашников виноват, что 98% пуль летят мимо цели? Наверно вы за то, чтобы допускать к программированию только обладателей диплома? Когда до вас дойдет, что мир не совершенен? Нет такого профессионального инструмента, которым не пользовались бы не по назначению и так будет впредь. На PHP, хоть я его и не праздную, было написано немало хороших, профессиональных программ. И на Java-Scala-Erlang не смотря на более высокий порог вхождения написано немало фигни. Не надо сокрушаться о вселенной. Просто пишите свой код настолько качественно, насколько можете и это почти всё, что можете сделать вы. Не заплевывать технологию только за то, что туда привлекают начинающих, а реально делать качественный код и популяризировать профессиональные подходы к программированию.

takkmoil Oct 4 2011 at 09:17

Тед приводит доказательства блокирования потока процессорными вычислениями (не воспользуются менее-чем-эксперты тиками, нет), а не блокирования сервера отдачей данных клиенту.

proxor Oct 4 2011 at 09:21

Я как-то не обратил внимания, думал речь идёт об отзывчивости сервера. А тут вона как, внезапные срывы покровов, 2-й курс универа!

smartov Oct 4 2011 at 09:33

Какой ужас-то :) Поток блокируется. Приложение на потоки для того и разделяют, чтобы при блокировании одного, не блокировались остальные. Это суть потоков. Ожидать, что никакой из них никогда не заблокируется бессмысленно. Иначе начерта они нужны, можно всё тогда синхронно лабать.

takkmoil Oct 4 2011 at 09:52

Почитайте сайт Node. «Nothing blocks» сложно воспринимать иначе, чем «ничего не блокируется». Автор не зря начинает статью с объяснения, почему эти утверждения — откровенная ложь.

smartov Oct 4 2011 at 10:00

Автор придирается к словам ради красивого троллинга и не более. С таким же успехом я могу, например, начать исходить слюной по поводу того, что на сайте Mozilla написано «Простой и лаконичный интерфейс позволяет освоить программу за несколько минут.»

И я такой заряжаю пост «Крах UI Mozilla. Блядская система addonoв» и тому подобное, на полном серьёзе пытаясь доказать что за несколько минут программу освоить невозможно.

(Надеюсь я не спалил идею для поста...)

takkmoil Oct 4 2011 at 10:03

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

orcy Oct 4 2011 at 10:16

Ну так это не дельная вещь, а банальность. Если бы эта идея была бы хоть как-то аргументирована, было бы интереснее.

dikarik Oct 4 2011 at 20:14

Эту банальность забыло 8 человек из 10. Поэтому мы имеем HTML5-приложения в мобильных телефонах. Тот самый HTML5, в на любую задачу есть два параллельных и никак не взаимодействующих решения. Поэтому мы имеем джаваскрипт в качестве единственного браузерного языка вместо байткода или подхода NaCL. Поэтому мы долго имели Apache + mod_php на подавляющем большинстве сайтов. Поэтому мы имеем фанатиков разнообразных подходов — будь то ООП, ФП, TDD или Agile, кричащих, что они нашли серебряную пулю. Вне IT мы имеем истерию против ГМО и молитвы на всё натуральное (я тут вообще недавно видел рекламу какой-то косметики со строкой «не содержит химических веществ»).

Нет уж, напоминание о том, что надо думать головой никогда не лишне.

david_mz Oct 5 2011 at 16:14

Все описанные ужасы (Apache + mod_php, html5, js повсюду и т. д.) как раз и привели к тому, что Вы можете сидеть на хабре и ворчать в своё удовльствие. Без энтузиастов, осваивающих всё новое, мы бы до сих пор без штанов за мамонтами бегали.

Думать головой, конечно, надо, только вот переведённый текст этому отнюдь не способствует — он попросту глуп.

dikarik Oct 5 2011 at 19:22

Если говорить конкретно обо мне — то хабр я не сичтаю венцом прогресса, и ворчать в ньюсах мне гораздо удобнее.

Что касается текста — это он ещё мало обругал человека, пытающегося в рекламе своего продукта врать, что масштабируемость — это легко, когда никакой лёгости там и близко нет.

Кто хочет лёгкую масштабируемость — пусть берёт эрланг, он простой на самом деле. Только там тоже думать понадобится — хотя бы о том, чтобы лишние потоки данных не гонять между разными машинами.

david_mz Oct 5 2011 at 19:24

Чёрт, а я уже почти поверил, что хотя бы в Эрланге думать не надо будет. Облом…

masterbo Oct 5 2011 at 19:31

А вы ничего не путаете? Например отсутствие I/O блокировок с масштабируемостью? Или мы с вами разную рекламу видели?

dikarik Oct 5 2011 at 20:05

Наверное, разную — я видел именно рекламу вроде «нод в отличие от апача держит огромное количество запросов». Понятно, что горизонтально его не отмасштабировать.

masterbo Oct 5 2011 at 23:33

Вы сами понимаете, что «нод в отличие от апача держит огромное количество запросов» ничего о масштабируемости не говорит? Нод действительно может обслужить больше параллельных запросов чем апач на том же сервере.

masterbo Oct 5 2011 at 21:23

masterbo Oct 5 2011 at 23:28

masterbo Oct 4 2011 at 13:14

Я только что читал его пост про NoSQL. Все его аргументы сводятся к тому, что раз реальный бизнес пользуется SQL, значит NoSQL это фигня. Вы тоже разделяете такую логику?

lega Oct 4 2011 at 09:24

Torando точно так же блокируется процессорным вычислением, автор просто не понимает принципа асинхронных фреймворков и их применения.

BVadim Oct 4 2011 at 09:32

Вероятнее всего автор просто искусно тролит.

takkmoil Oct 4 2011 at 09:57

Автор всё прекрасно понимает. Он делает вид, что он менее-чем-эксперт, берёт пример из документации, пишет в него свой функционал (разве не так поступают начинающие?) и получает результаты прямо противоположные заявленным, прекрасно доказывая, что вся маркетинговая шелуха — чистая ложь и всё не так просто, как заявлено автором. Ну а unix way — это любимая тема автора, и я с ним во многом согласен.

smartov Oct 4 2011 at 10:12

Почему ложь? Почему автор ставит знак равно между «не блокируется» и «выполняется мгновенно блеать»? Или фибоначчи должны были посчитаться за минус 0.1 микросекунды из-за неблокирования? Нет. Ну так в чем проблема? Автор объясняет что даже неблокирующиеся программы требуют время на выполнение? Тогда не хватает ещё объяснения что они ещё и память требуют. Он бы тогда создал массив гигов на 10 и кричал что ноджс говно, потому что на его старом ноуте с 256 мегами оперативы всё тормозит.

dmitriid Oct 4 2011 at 14:07

Он не ставит знак равно. Он говорит, что CPU-bound программы — это тоже блокирующие программы.

smartov Oct 4 2011 at 14:13

habrahabr.ru/blogs/nodejs/129640/?reply_to=4294764#comment_4294192

dmitriid Oct 4 2011 at 14:22

Теперь читаем внимательно:

На сайтe Node.js сказано:
В Node практически нет функций, напрямую выполняющих операции ввода-вывода, так что процесс никогда не блокируется. Из-за того, что ничего не блокируется, менее-чем-эксперты могут разрабатывать быстрые системы.

Сколько из «менее-чем-экспертов» способны понять, что выделенное выше относится к I/O и только к I/O?

dikarik Oct 5 2011 at 19:35

И ещё одно — вторую претензию автора тоже не стоит забывать — а состоит она, напомню, в том, что нод — плохой комбайн. С одной стороны, в нём лишний раз реализован HTTP-сервер (вместо, к примеру, на порядок более простого FastCGI-сервера), а с другой — этот сервер примитивен, что всё равно заставляет держать какой-нибудь nginx. При этом администрирование сервера и модификация программной логики поневоле будут свалены в кучу.

seriyPS Oct 4 2011 at 13:57

Tornado в этом плане от Node.JS ничем не отличается.

orcy Oct 4 2011 at 09:10

BREAKING NEWS: фибоначи блокируют поток!

bobrik Oct 4 2011 at 10:13

Слава богу он умер уже!

masterbo Oct 4 2011 at 13:18

Вам не объяснили на первом курсе почему это не новость?

smartov Oct 4 2011 at 09:30

Автор, конечно, пишет хуергу, с которой даже спорить нет смысла, поскольку его аргументация просто несостоятельна. Впрочем выше в камментах всё уже написали.
НО
Вы отлично перевели текст. Переводите хорошие тексты дальше, пожалуйста :)

bobrik Oct 4 2011 at 10:12

Автор — знатный наркоман.

> In the past year I think I have finally come to understand the ideals of Unix: file descriptors and processes orchestrated with C. It's a beautiful idea.

> очередное нытьё какого-то осла о том, что Unix слишком сложен

Об остальном даже говорить не хочется. Ни про мутантов, вешающих между nginx и nodejs что-то ещё, ни про тех, для кого fibonancci без memorize в веб-сервере ЩИТО ВООБЩЕ ВЫ ТАМ ЧТО СЕБЕ В ВЕНУ КОЛЕТЕ?

UFO just landed and posted this here

Jodes Oct 4 2011 at 11:23

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

Burantino Oct 4 2011 at 11:31

Единственное, что я почерпнул из этой статьи: «Боль в жопе непременно появится, если засунуть туда грабли». И не поспоришь ведь. Берегите здоровье — осторожнее с граблями, куда попало не суйте.

dimitrymd Oct 4 2011 at 11:34

Технологии разные нужны, технологии разные важны) Оставим проблемы приложений/серверов node.js тем, кто эти проблемы создает. Не нужно устраивать крестовые походы. Если технология стоящая — она выживет и многие недостатки ее будут устренены, если нет — она канет в лету. Время все покажет! Зачем холивары? Ты программист PHP и не хочешь переходить на node.js — какие проблемы? Не переходи! Лучшая технология для тебя — та, которой ТЫ владеешь, тонкости и ньюансы которой ТЫ знаешь и понимаешь НА ГЛУБОКОМ УРОВНЕ, когда ты с ними сталкивался и их прочувствовал, когда твое понимание технологии выстрадано, а не просто изучено. А что до ограничений… любая технология имеет свои плюсы, и свои минусы.

david_mz Oct 4 2011 at 11:37

Прочитав, хочется спросить — дядя Тед, ты дурак? Хотя понятно, на самом деле, что не дурак, а тролль.

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

1. Ах, Нода тратит CPU — ВСЁ тратит CPU. Ежу понятно, что любой код исполняется на CPU, а не в квантовом мультиверсе. Если дядя Тед знает хоть одну технологию проограммирования, не тратящую вычислительные ресурсы — мы его внимательно выслушаем. Но несмотря на то, что всё тратит процессорное время, это время — самый дешёвый из имеющихся ресурсов. Заставить веб-сервер упереться в процессор ОЧЕНЬ сложно. Он гораздо раньше упрётся в диски, в сеть, в БД… Исключение блокировок диска, сети, БД и т. п. позволяет использовать CPU максимально эффективно. Это и называется «не блокировать поток исполнения» — потому что поток исполнения не останавливается и не ждёт внешних ресурсов. А то что при написании таких «неблокирующих» программ всё равно надо думать головой — это никто не отменял. Нода сама по себе от написания цикла while(true) {} не защитит. Как и PHP, Java и кто угодно ещё.

2. Ах, Нода не юникс-вей, ой-вей. Ни в одной (ещё раз: ни в одной) реально работающей системе невозможно обойтись одним уровнем обработки запросов. На любом более-менее посещаемом сайте вначале стоит Nginx или что-то вроде, а потом стоит бэкенд, обрабатывающий динамику. Даже если бэкенд сам по себе умеет обрабатывать внешний HTTP (как апач, например), Nginx, как в том анекдоте про папу Вовочки и быка, просто сделает это лучше. Нода — одна из компонент для построения многокомпонентной системы, не более. А реальные системы НЕ БЫВАЮТ однокомпонентными. И это не «ещё один уровень мониторинга», а ещё один уровень функциональности и надёжности.

3. Любить или не любить JavaScript — вопрос исключительно вкусовой.

4. Использовать или не использовать Node.js — тоже.

vlm Oct 4 2011 at 16:18

От while(true) {} защитит Erlang. У него ничего не сломается от такого.

masterbo Oct 4 2011 at 16:36

Пост не про Erlang, а про «не совместимые с жизнью» проблемы node.js

vlm Oct 4 2011 at 16:44

Я предлагаю альтернативу проблемам node.js, так что мой коммент в тему.

masterbo Oct 4 2011 at 17:18

А я пользуюсь Tornado, а не node.js. Вы считаете мне тоже надо написать о его отличиях, даже если это будет офтопом?

vlm Oct 4 2011 at 21:45

Вообще-то да. Но отличий в Tornado от Node.JS практически нет — те же грабли, вид сбоку. Вот сравнение Erlang'овского веб-сервера и Tornado:

lionet.livejournal.com/42016.html

masterbo Oct 5 2011 at 01:19

Спасибо за ссылку, но информация там не полна: «No, I haven't tried it [Tornado] on Linux with epoll». OTP интересная штука, присмотрюсь.

david_mz Oct 4 2011 at 16:54

Видите ли, в PHP тоже ничего глобально не сломается — просто процесс будет грохнут апачем через заданный таймаут. Но это же не значит, что так и надо писать.

masterbo Oct 4 2011 at 17:34

Вы не ощущали как тормозит сервер, у которого Apache + mod_php так размножились в памяти, что ушли в swap? А такое легко случается с синхронными приложениями при высокой нагрузке. Тогда как асинхронные всего-лишь могут выпасть по таймауту при переполнении запросами. То есть система останется стабильной и обслужит максимум запросов максимально используя ресурсы. Node.js на мой взгляд не лучший представитель этой архитектуры, но то, что пишет автор — просто бред.

dobriykot Oct 4 2011 at 17:49

По первому пункту хотелось бы поделиться с теми, кто не читал «C# via CLR» Рихтера, небольшим отрывком про потребление CPU.

UFO just landed and posted this here

naryl Oct 4 2011 at 12:05

Перезалейте, пжлст, статью Райана Дала куда-нибудь. У меня длинный белый лист открывается.

takkmoil Oct 4 2011 at 12:13

Вот. Там тоже есть с чем поспорить, кстати.

naryl Oct 4 2011 at 13:09

Благодарю.

Что-то у него общего есть с кодерами из suckless.org только он, похоже, ещё и отрицает существование понятия «внутреннее качество», а suckless напротив, считают разработчика первым и самым главным пользователем.

К топику:

> люди, использующие его, инфицируют других людей, не умеющих думать самостоятельно, пока, в конце концов, каждый встречающийся мне мудак не начинает читать проповеди

Легко применимо к любой новой технологии, разработанной в корпорации с хорошими маркетоидами, умеющими раздувать из идей тридцатилетней давности *новые* баззворды.

Aco Oct 4 2011 at 12:19

Стано что никто не удивился алгоритму подсчета чисел фибоначи, капитально вызывающий рекурсию и считающий хрен знает что…

takkmoil Oct 4 2011 at 12:21

Считает он вполне себе числа Фибоначчи, самым простым методом. И для удивляющихся есть комментарий про замкнутое решение. Это классический синтетический тест.

Aco Oct 4 2011 at 12:22

Вот странно, у меня на нескольких языках, влкючая JS, уходит в рекурсию

takkmoil Oct 4 2011 at 12:25

Так это рекурсия и есть. Почитайте подробнее про числа Фибоначчи.

Aco Oct 4 2011 at 12:54

а Вы запускали эту функцию?
fibonacci(40);

takkmoil Oct 4 2011 at 12:58

Да, а что?

Aco Oct 4 2011 at 13:01

Нащупал интересную вещь, эта функция работает ТОЛЬКО на v8.

takkmoil Oct 4 2011 at 15:26

Вы хотели сказать, быстро работает?

mx2000 Oct 4 2011 at 18:17

вероятно, товарищ Aco хотел сказать, что у него вычисление fib(40) выжирает стэк со всеми вытекающими :)

Aco Oct 4 2011 at 12:56

Отлично справился циклом for без рекурсий.
ПС под рекурсией в имел ввиду программную рекурсию

Aco Oct 4 2011 at 12:21

Возможно ли такое что ядро V8 дало отлуп рекурсии через 5 секунд (как в браузерах)?

takkmoil Oct 4 2011 at 12:26

Нет, он вывел в консоль верный ответ, 165580141, это 41е число Фибоначчи.

Disasm Oct 4 2011 at 12:41

Мда уж. Автор нашёл слабое место v9, и показал как плохо сервер работает, используя это слабое место. А то что если заставить nodejs отдавать статический контент, даже если он будет на лету генерироваться с помощью шаблонизатора, и при этом получить производительность порядка 10000 запросов в секунду, про это мы не говорим, ага.
Переводчику спасибо, узнал что бывают такие истерички.

xxxYURAxxx Oct 4 2011 at 23:28

лень искать пруф, но сысоев(автор nginx) говорил node.js не потянет 8k hello world'ов

Zelgadis Oct 6 2011 at 00:23

Игорь Сысоев (имена с большой буквы пишутся) говорил о том, что node.js с его v8 не встраиваемый.

ragus Oct 5 2011 at 08:55

не выдаст нода вам столько rps. да еще и скорее всего cpu usage будет 100% для ядра, на котором запущена.
afaik, про sendfile(2) она не в курсе.

xdenser Oct 5 2011 at 09:58

Что я делаю не так?

ab -c 90 -n 20000 127.0.0.1:1337/
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, www.zeustech.net/
Copyright 2006 The Apache Software Foundation, www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 2000 requests
Completed 4000 requests
Completed 6000 requests
Completed 8000 requests
Completed 10000 requests
Completed 12000 requests
Completed 14000 requests
Completed 16000 requests
Completed 18000 requests
Finished 20000 requests

Server Software:
Server Hostname: 127.0.0.1
Server Port: 1337

Document Path: /
Document Length: 12 bytes

Concurrency Level: 90
Time taken for tests: 1.982625 seconds
Complete requests: 20000
Failed requests: 0
Write errors: 0
Total transferred: 1520000 bytes
HTML transferred: 240000 bytes
Requests per second: 10087.64 [#/sec] (mean)
Time per request: 8.922 [ms] (mean)
Time per request: 0.099 [ms] (mean, across all concurrent requests)
Transfer rate: 748.50 [Kbytes/sec] received

Connection Times (ms)
min mean[±sd] median max
Connect: 0 0 0.3 0 7
Processing: 2 8 1.8 8 18
Waiting: 2 8 1.8 8 18
Total: 2 8 1.8 8 18

Percentage of the requests served within a certain time (ms)
50% 8
66% 8
75% 8
80% 8
90% 9
95% 13
98% 16
99% 16
100% 18 (longest request)

takkmoil Oct 5 2011 at 10:00

Характеристики тестовой машины в студию, пожалуйста.

xdenser Oct 5 2011 at 10:07

Intel Core i5 2400 3.1Gghz, но тест идет под виртуалкой VMWare, виртуалке отдано 4 ядра и 1 Гиг памяти.
С одним ядром дает около 7000 rps, но надо учитывать, чо бенчмарк тоже на этой же виртуальной машине работает. Так что выходит одно ядро грузится нодой, а остальные 3 бенчмарком.

xdenser Oct 5 2011 at 10:04

да 20000 запросов маловато, переделал с 1 000 000 запросов — результат тот же.

ragus Oct 5 2011 at 16:40

Document Length: 12 bytes

Ооох… вы невнимательно прочитали мой ответ. речь шла о 10k rps на статическом контенте.
Вы померили отдачу хелловорлда, что в реальной жизни никому неинтересно.

Рассказываю, как мерить правильно:

создаем файлики на 1к, 2к, 4к, 8к и запускаем ab2 меняя concurrency ( -c ключ) измеряя rps на отдаче этих файликов.

masterbo Oct 5 2011 at 17:56

Мне оказалось или вы предлагаете отдавать статику через node.js?

ragus Oct 5 2011 at 18:43

это Disasm предлагает статику раздавать. И не вижу ничего плохого в раздаче статики через node.js (ведь мы же претендуем на полноценный server side? )

masterbo Oct 5 2011 at 19:19

Вы широким жестом отдаете v8 заниматься работой, для которой написан nginx? Вам это не кажется неоправданным пижонством?

ragus Oct 6 2011 at 05:39

я предложил рассмотреть самый простой случай. в реальной жизни это может быть не отдача 1 файла, а «разобрать GET-запрос, в зависимости от параметров выбрать первый файл с которого отдавать и смещение относительно его начала, после чего отдать цепочку файлов клиенту» (т.е. сделать нечто вроде cat part0 > file && cat part1 >> file && cat part2 >> file… ).

И тут возникает дилемма: либо писать модуль для nginx, либо писать что-то свое.
В приведенном мной примере логики немного, а когда с начальными/конечными параметрами определились, надо просто дергать sendfile(2). я выбрал gevent(и на текущий момент упираюсь либо в диски, либо в сеть).

Я предложил потестировать одну из лимитирующих производительность частей — отдачу с диска фрагмента клиенту. А тестить отдачу 12 байт клиенту — весьма сомнительный бенч.

masterbo Oct 6 2011 at 12:06

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

andoriyu Oct 6 2011 at 01:07

И много ли людей используют такое решение? Статику всегда отдает фронтенд сервер, в то время как app-сервер занимается тем, чем он должен заниматься. Если так интересно, то могу провести желанные вами тесты.

ragus Oct 6 2011 at 05:45

да, тесты интересны. и статика, она ведь разная бывает. например, live-трансляция, когда всем клиентам отдаются одни и те же данные(фактически, разновидность чата), а на ноде почти поголовно предлагают писать чаты.

В статье ноду трэшат cpu-bound задачей. Так давайте возьмём io-bound, на которые так хорошо ложится event loop: раздача всем клиентам одинаковых данных.

PS: я эту задачу для себя решил: 19k клиентов в онлайне, 2Гбит/с исходящего трафика(у меня пока нет 10GE для тестов).

Zelgadis Oct 6 2011 at 07:05

> и статика, она ведь разная бывает.
> live-трансляция
Статика такая статика.

ragus Oct 6 2011 at 07:15

для вашего успокоения: представьте, что это с диска раздаётся ;)

Zelgadis Oct 6 2011 at 07:27

Нет, я не буду писать erlyvideo на node.js. Хотя бы потому, что уже есть готовый production-ready продукт.

ragus Oct 6 2011 at 07:39

erlyvideo — это такой комбайн. я говорю о более простой задаче. Выше я привёл цифры. не думаю, что для ноды это вызовет какие-то проблемы.

Zelgadis Oct 6 2011 at 07:48

Как бы быстро перешли от disk-io к network-io и опять используем node.js вместе продукта который уже довольно таки развит (nginx). Если бы мне надо было раздавать файлы постоянно, то я бы использовал node.js только как роутер не говоря уже про кэш в оперативной.

А если так хочется гонять числа фибоначи, то всегда можно соорудить очередь с воркерами.

Довольно странное занятие вы нашли, пытаетесь убедить человека который знает, что серебряной пули не существует в том, что ее не существует…

ragus Oct 6 2011 at 08:08

опять nginx. ну хорошо. покажите мне пример, как на nginx в рамках _ОДНОГО_ http-запроса отдать клиенту файлы file0.part и file1.part
и где нода у вас будет как роутер.

http-сервер в node.js/gevent/tornado/twisted/eventmachine позволяет делать всё что угодно в процессе обработки запроса и встроить любую логику в обработку запроса на любом этапе
(вот опять же, попробуйте в nginx после завершения передачи файла клиенту выставить ключ в memcached, что файл отдан клиенту целиком).

Zelgadis Oct 6 2011 at 08:20

Ну тогда это уже не статика. И тут совсем другой разговор. В _этой_ ветке речь шла про статику, про разные части разных файлов в один http запрос это вы с masterbo говорили. Ну раздавайте через node.js/любой другой инструмент который подходит (хотя лично я не могу придумать когда это такое потребуется, но ладно)

ragus Oct 6 2011 at 08:34

это может понадобиться для создания архива live-эфира. видео пишется на диск фрагментамт(например, по 1 часу).
По крону ходит скрипт и подчищает всё, что старше, например, 1 месяца.

ragus Oct 6 2011 at 08:28

а про переход disk-io/network-io — забавно. какая разница, всё равно это i/o. Основное правило для event loop не нарушено: нельзя что-то долго делать (считать или использовать блокирующий i/o).

я не пытаюсь вас убедить в отсутствии серебряной пули. вы предлагаете соорудить на nginx заведомо нерабочую конструкцию.
я знаю, что nginx прекрасно отдаёт статику(как и динамику через разные fastcgi/uwsgi), я знаю про X-Accel-Redirect и там где надо использую и, вообще, всячески за использование nginx агитирую.

Но когда вам нужна кастомная обработка запроса(например, сделать seek по файлу на значение из параметра offset) вы приходите к написанию модуля для nginx.

Идея посмотреть как нода раздает файлы:
1)проста для повторения
2)достаточно наглядна
3)интересна в сравнении с аналогичными вещами(gevent/eventmachine)

это не призыв использовать такое в реальной жизни без особой необходимости.

Zelgadis Oct 6 2011 at 08:36

> а про переход disk-io/network-io — забавно. какая разница, всё равно это i/o. Основное правило для event loop не нарушено: нельзя что-то долго делать (считать или использовать блокирующий i/o).

www.slideshare.net/frank06/nodejs-riak

На каком-то из первых слайдов очень хорошо показана разница.

> я не пытаюсь вас убедить в отсутствии серебряной пули. вы предлагаете соорудить на nginx заведомо нерабочую конструкцию.

Перечитайте еще раз, что я сказал. Я говорил о статике, а не о том, что вы называете статикой — соорудить в рантайме из пачки файлов один фаил это не статика.

> Но когда вам нужна кастомная обработка запроса(например, сделать seek по файлу на значение из параметра offset) вы приходите к написанию модуля для nginx.

Да, правда кроме как для раздачи mp4 (модуль уже в core есть) мне эта фича не нужна, другое дело Streaming API.

> Идея посмотреть как нода раздает файлы:
1)проста для повторения
2)достаточно наглядна
3)интересна в сравнении с аналогичными вещами(gevent/eventmachine)

Уже вижу, что разница будет минимальна, попробуйте догадаться почему.

ragus Oct 6 2011 at 16:37

>соорудить в рантайме из пачки файлов один фаил это не статика.

т.е. только из-за того, что n файлов улетают клиенту в рамках 1 запроса — это уже не статика? я же не генерирую их в рантайме. с точки зрения веб-сервера нет разницы между:

socket = accept()
read_request()
write_headers()
fd = open(«part0.bin»)
sendfile(socket, fd, 0, len)
close(fd)
close(socket)

и

socket = accept()
read_request()
write_headers()
fd = open(«part0.bin»)
sendfile(socket, fd, 0, len)
close(fd)
fd = open(«part1.bin»)
sendfile(socket, fd, 0, len)
close(fd)
fd = open(«part3.bin»)
sendfile(socket, fd, 0, len)
close(fd)
close(socket)

>Да, правда кроме как для раздачи mp4 (модуль уже в core есть) мне эта фича не нужна, другое дело Streaming API.

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

Zelgadis Oct 6 2011 at 21:46

> т.е. только из-за того, что n файлов улетают клиенту в рамках 1 запроса — это уже не статика?

Если кол-во файлов и их расположение не известно заранее — да, это уже не будет статикой.

> mp4 не подходит для этих целей, к сожалению. Этот контейнер требует предварительной обработки, прежде чем им можно будет пользоваться для стриминга.

Конвертации в Baseline Profile? И добавлении payload? Если надо работать с видео не понимаю почему бы не использовать erlyvideo.

ragus Oct 6 2011 at 22:29

>Если кол-во файлов и их расположение не известно заранее — да, это уже не будет статикой.

Т.е. от того, что в соковыжималку мы положили сразу 2 апельсина, а не поштучно — от этого они перестают быть апельсинами? ;)

>Конвертации в Baseline Profile?
как связан профиль h.264 с контейнером?

>И добавлении payload?
какой еще payload? payload — это данные.

>Если надо работать с видео не понимаю почему бы не использовать erlyvideo.

потому что erlyvideo предназначен для другого и то что нужно нам он не умеет.

Теперь будет про mp4:

H.264 files and metadata
In H.264-based video formats (mp4, m4v) the metadata is called a «moov atom». The moov atom is a part of the file that holds the index information for the whole file.

Many encoding software programs such as FFMPEG will insert this moov atom information at the end of the video file. This is bad. The moov atom needs to be located at the beginning of the file, or else the entire file will have to be downloaded before it begins playing.

Т.е. mp4 предварительно надо обрабатывать. Теперь, самое грустное: т.к. пишем мы live-эфир, то конца файла не будет. Ни завтра, ни через месяц. Зато за это время у нас набежит много гигабайт данных и у нас может кончиться место на диске.
В комментах поста про эту статью у Lev Walkin было предложено написать видеосервер на ноде и сравнить.

Можно не брать rtmp, а взять более простой для работы mpeg-ts (там максимум час времени с отладкой).

PS: товарищи минусующие, а по делу есть что сказать?

Zelgadis Oct 6 2011 at 22:39

> Т.е. от того, что в соковыжималку мы положили сразу 2 апельсина, а не поштучно — от этого они перестают быть апельсинами? ;)

Какой плохой пример. Вот, вы уже ушли от тему в сторону черных способов спора.

> как связан профиль h.264 с контейнером?

Только косвенно.

> какой еще payload? payload — это данные.

Mp4 умеет еще нести с собой hint payload для стриминга.

> потому что erlyvideo предназначен для другого и то что нужно нам он не умеет.

Понимаете, бывает, что человеку надо одно, и он решает свою проблему через жопу. Потом ему говорят, что есть же вот такой инструмент который поможет. Человек пытается натянуть жопу на этот инструмент (вместо того, чтобы избавиться от костылей и использовать все по назначению — пытается использовать инструмент вместе с теме костылями от которых надо избавиться). Это случайно не ваш случай?

> Many encoding software programs such as FFMPEG will insert this moov atom information at the end of the video file. This is bad. The moov atom needs to be located at the beginning of the file, or else the entire file will have to be downloaded before it begins playing.

Не используй ffmpeg, там генерация mp4 уже давно сломана.

> В комментах поста про эту статью у Lev Walkin было предложено написать видеосервер на ноде и сравнить.

Я бы разделил трансляцию и сохранение не разные приложения.

erlyvideo Oct 23 2011 at 16:04

Простите, но про MPEG-TS, который максимум час с отладкой — это наглая и неприкрытая ложь.

ragus Oct 24 2011 at 01:01

Почему же? если не разбирать сам mpeg-ts, а считать его просто как bytestream. Единственная потенциальная проблема — клиенты могут понять его не как mpeg-ts, а какой-нибудь mpeg-ps

vkramskikh Oct 4 2011 at 12:51

Автор в статье перечисляет прописные истины, которые узнает каждый, кто внимательно слушает «проповеди об event loop». Внезапно, у каждого инструмента есть своя область применения, в которой он наиболее эффективен, и есть задачи, на которых его использовать совершенно не нужно. nginx, например, тоже использует event loop, но никто же не скажет, что он раковая опухоль в мире веб-серверов, ибо выполняет многие типичные для веб-сервера задачи лучше thread/process-based серверов

> полный боли в жопе пост от Райана Дала
Пост, полный боли в жопе более чем этот, надо ещё поискать :)

takkmoil Oct 4 2011 at 12:54

Да ну не воспринимайте серьёзно. Автор передёргивает, гиперболизирует и издевается давнным-давно, в каждом посте. У него такой стиль, это как Лебедев, но в IT и за бугром.

vkramskikh Oct 4 2011 at 13:05

Да это понятно. Просто очень плохой троллинг, я думал намного лучше будет :) Это как называть ассемблер раковой опухолью лишь потому, что кто-то на нем додумался веб-сервисы делать

masterbo Oct 4 2011 at 13:26

Лебедев хоть разбирается в том, что критикует.

takkmoil Oct 4 2011 at 15:23

«Не разбирается» и «передёргивает ради троллинга» — совсем разные вещи.

masterbo Oct 4 2011 at 16:03

В данном случае не разбирается. Иначе бы не имел мотива троллить.

egorF Oct 4 2011 at 12:59

обоже, этот вброс перевели на русский и началось тоже самое %-)

octave Oct 4 2011 at 13:55

Егор, давай на украинский переведем :)

egorF Oct 4 2011 at 14:01

Хмм, комедии на украинском смешные, а украинофилы — это отличная еда.

TedBeer Oct 4 2011 at 12:59

Автор — просто тролит сообщество и этого не скрывает.

Nickname Oct 4 2011 at 13:36

Епт, ну сюда-то зачем этот бред было переводить.
Как контраругмент: github.com/glenjamin/node-fib — быстрый Фибоначии сервер. Но вообще вся статья не в кассу.

ComodoHacker Oct 4 2011 at 13:47

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

Я не хочу разговаривать матом еще и на Хабре.

vasilievvv Oct 4 2011 at 14:18

Алгоритм, который автор использует для вычисления чисел Фибоначчи — это феерический ппц, потому что в нём шизофреническое количество повторных вычислений, и для числа пять подсчёты выглядят подобным образом:

Для подсчёта чисел Фибоначчи нужен цикл, тогда каждый член считается один раз:

<code>function fib_loop(n) {
  fib = [ 1, 1 ];
  for( i = 2; i <= n; i++ )
    fib[i] = fib[i-1] + fib[i-2];
  return fib[n];
}</code>

И выполняется это за доли секунды!

aspect Oct 4 2011 at 15:13

что вы все упёрлись в алгоритм, автор хотел продемонстрировать ресурсоёмкое вычисление по памяти и процу

Zelgadis Oct 6 2011 at 01:11

Пытался вкрутить гвоздь лопатой в камень — лопата это раковая опухоль.

takkmoil Oct 4 2011 at 15:24

Для вас он написал ремарку под алгоритмом.

el777 Oct 4 2011 at 19:20

Вы не поняли — автору как раз нужно было сделать кучу лишних вычислений, чтобы загрузить процессор.
Ему не нужны сами числа, ему нужно кулером на проце погудеть :)
Неоптимальный рекурсивный алгоритм для этого — самое оно.

Sibarit Oct 4 2011 at 15:15

Уважаемый takkmoil, Вы отлично справились с переводом.

Даже не будучи программистом, но кое-что в этом понимая, с удовольствием прочитал от и до — круто.
Не слушайте ханжей, смело передавайте стиль автора, даже если это требует нецензурщины. Главное — результат. Вы однозначно дали стране угля.

takkmoil Oct 4 2011 at 15:24

Спасибо :)

GrossHo Oct 4 2011 at 15:43

Я утратил веру в числа фибоначи :( Я конченный человек.

kolyuchii Oct 4 2011 at 15:45

Иногда кажется, что айтишники забывают зачем они нужны. Сам по себе труд — никому не нужен. Важен только результат этого труда.

vlm Oct 4 2011 at 15:51

Точно такой же код на Erlang выполняется в разы быстрее, чем на Node.JS:

lionet.livejournal.com/95346.html

При этом в Erlang ничего не блокируется и не трещит по швам из-за концепции независимых асинхронных потоков без общей памяти.

Nickname Oct 4 2011 at 16:23

Вы смотрели-то на цифры, приведенные по ссылке? 6 секунд Node.js, 24 секунды интерпретируемый erlang, 12 секунд скомпилированный erlang. И при чём тут node.js вообще, если скорость в данном случае зависит от скорости интерпретации V8…

vlm Oct 4 2011 at 16:34

Erlang: 6 секунд Erlang, 24 секунды интерпретируемый Erlang
Node.JS: 12 секунд Node.JS

И да, это V8.

masterbo Oct 4 2011 at 16:42

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

vlm Oct 4 2011 at 16:45

Автор тролль, я об этом уже написал здесь lionet.livejournal.com/95346.html

Это не отменяет того, что в Node.js есть проблемы, которые решены десятилетия (!) назад в других языках.

masterbo Oct 4 2011 at 17:22

Node.js не язык, а однопоточный сервер приложений на языке javascript. То, что автор указал как трагедию, не трагедия, а глупость. Он занял процессор на 5 секунд и начал негодовать, что все 5 секунд ему пришлось ждать результата. На своем любимом Django он получил бы точно такой же результат — 5 секунд ожидания. Это не проблема Node.js. Хотя в нем проблем действительно хватает.

mx2000 Oct 4 2011 at 18:28

Проблема в том, что Node.js преподносится как универсальный молоток. А это ест мозг не только девелоперам, но и бизнесу, который говорит примерно так: «мы тут начинаем новый проект, у нас будет много-много тро-ло-ло, поэтому мы хотим юзать node.js. Мы слышали, что он крутой».

И по факту получается, что на ноде девелоперы пилят нечто отдаленно напоминающее OTP/Erlang, только кривое и бажное. Спрашивается, накуя?

masterbo Oct 5 2011 at 01:29

«Пусть распустятся сто цветов, пусть откроются сто школ». Какая вам разница что кто-то будет делать свой проект на «не правильном» с вашей точки зрения фреймворке? Коснется вас, тогда и аргументируйте своему системному архитектору или инвестору, что вы собираетесь придерживаться другой школы. Рынок всё расставит по своим местам. Не досужая болтовня о том, что кто-то не прав, а конкретные проекты с конкретной выручкой. Так пусть дерзают. Повезет — разовьют эту технологию до каких-то высот, не повезет — дадут опыт набитых шишек. Всё это ценно, а неконструктивная критика — нет.

sdramare Oct 4 2011 at 16:37

Весь пост автора сводится к

А дальше очень много эмоций и мата по поводу того, что разработчики Node.js не рассказали об этом автору.

david_mz Oct 4 2011 at 17:20

Ничего не имею против эрланга, но доказывать его превосходство на таком заведомо неоптимальном алгоритме — довольно странное занятие.

vlm Oct 4 2011 at 21:47

Оптимальность алгоритма — дело десятое, когда его результаты просто выкидываются. Нужно было занять VM какими-то рекурсивными расчётами, вот и заняли. То, что алгоритм неоптимальный — только на руку: нам же VM нужно протестировать, а не наиболее эффективно подсчитать n'ное число фибоначчи.

Nickname Oct 4 2011 at 16:29

Я удивлен, сколько же людей не понимают, что в приведённом примере Node.js вообще не при чём. Там используется тяжелый алгоритм(ремарка не в тему), который тупо грузит CPU. А node.js — это в основном про асинхронное IO, когда вы легко можете загрузить CPU в _промежутках_ между выполнением IO.
А реальные проблемы Node.js — ограничение на 1 ГБ используемой памяти (из-за V8, но вроде собираются побороть это) и неэффективное использование ядер (нужно запускать несколько процессов Node.js).

Leeb Oct 4 2011 at 16:33

… и лапши из коллбэков, и в обработке ошибок, и…

masterbo Oct 4 2011 at 16:44

и еще куча всего, но эти реальные проблемы столько эмоций не поднимут, а автору надо было сильно обмануть не сведущего читателя чем-то эффектным.

drdim Oct 4 2011 at 16:44

Что мешает повесить глобальный обработчик?

process.on('uncaughtException', function (e) {

  try {

    sys.puts('Caught exception: ' + e + ' ' + (typeof(e) === 'object' ? e.stack : ''));

  } catch(e0) {}

});

И вообще, кода вы пишите код, то вы пишите его для того чтобы он некорректно завершался, или все же делаете хорошо продуманную программу?
Никто вас не заставляет писать на этом языке, у каждого языка плюсы и минусы, и нужно это понимать и этим пользоваться.

Leeb Oct 4 2011 at 16:51

Загвоздка в том, что в реальном мире случаются катастрофы. И с этим ничего не поделаешь, как бы хорошо ни продумывать.

> Никто вас не заставляет писать на этом языке
Так я и не пишу. Как правильно ответили выше, обсуждаются фатальные недостатки инструмента в контексте решаемых задач. Настолько фатальные, что на нем вообще лучше ничего не писать (в данном случае, конечно, серверного).

masterbo Oct 4 2011 at 17:16

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

BugEater Oct 4 2011 at 21:08

В учебнике по Erlang (Erlang programming By Francesco Cesarini, Simon Thompson) есть сравнение скорости выполнения функций с хвостовой и без хвостовой рекурсии: функции с безхвостовой рекурсии выполняются намного быстрее, так как сборка мусора происходит значительно реже.

Каким боком в данной статье node.js к скорости выполения V8 рекурсивной функции… это у автора нужно спросить.

jlbyrey Oct 4 2011 at 21:21

code.google.com/p/v8/issues/detail?id=847#c23

vaniaPooh Oct 4 2011 at 19:52

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

xdenser Oct 4 2011 at 19:55

О уже и тут..., а группа nodejs на Google Groups уже второй день гудит от этой статьи.
Кстати, там дали ссылку на «правильное» рекурсивное решение задачки для NodeJS

var app = require('express').createServer();

var fibonacci = function(n, callback) {
    var inner = function(n1, n2, i) {
        if (i > n) {
            callback(null, n2);
            return;
        }
        var func = (i % 100) ? inner : inner_tick;
        func(n2, n1 + n2, i + 1);
    }
    var inner_tick = function(n1, n2, i) {
        process.nextTick(function() { inner(n1, n2, i); });
    }
    if (n == 1 || n == 2) {
        callback(null, 1);
    } else {
        inner(1, 1, 3);
    }
}

app.get('/:n', function(req, res) {
    fibonacci(req.params.n, function(err, number) {
        res.send(''+number);
    });
});


app.listen(3000);

psQs Oct 4 2011 at 20:20

Интересно, долго ли тема про Node.js будет самой первой на странице. Когда «ВСЕ» было темы как то чаще менялись.

jlbyrey Oct 4 2011 at 20:40

Спасибо за перевод, понравилось. Интересно было почитать авторитетного рачка с форчана.

brainerazer Oct 4 2011 at 21:05

Красиво

brainerazer Oct 5 2011 at 07:36

Слава ompldr -_-

winolog Oct 5 2011 at 00:08

Блин!!! Жалко последние 4еро суток без сна за которые я делал GPS трекинг для большой компании на Node (((((( Из за того что заказчик настоял на Node и никакие аргументы не брали (

bohdan-shulha Oct 5 2011 at 00:45

Поскольку вас разочаровала статья с откровенным троллингом, что, дабы добить вас, могу посоветовать несколько статей на тему «мы все умрем». Будет весело, обещаю.

winolog Oct 5 2011 at 02:50

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

bohdan-shulha Oct 5 2011 at 02:53

Да что же неприятного? Сюда напрашивается картинка «в паутине кто-то неправ». Выбранная технология справляется с задачей, как вы говорите, неплохо, так что же еще нужно?!

winolog Oct 5 2011 at 02:54

Сон =).

wentout Oct 5 2011 at 11:27

Видимо он так и не понял, что достаточно Create Object (COM+ или что там на эту тему в *Nix) и возможности вызова JS интерпретатора из Shell | командной строки.

gen4 Aug 13 2015 at 10:33

Есть комментарии из будущего 2015?)

ZoomLS Oct 7 2015 at 13:14

IBM проталкивает ноду в интерпайз. Назад пути уже нет :)
На самом деле, столько лет прошло. Нода развивалась всё это время. Успела получить форк и вернуть его в себя. JS становится стандартом веб-разработки, когда нам хватит JS для всего, а узкие места можно сгладить написав библиотеку/модуль на C++.

takkmoil Oct 7 2015 at 13:32

А серебряной пулей так и не стала :-D

Arenim Dec 27 2016 at 18:07

Мде. Даешь некропосты, однако.

В общем, тут какое дело, ребяты… С одной стороны, мне очень нравится статья, особенно про UNIX-way, меня прям заводит. И пайпы, и CGI, и вот этовсё. И вообще, веб-сервер на bash, который лазит в сеть по inetd — это самый сок.

Но.

Правда в том, что ты все равно поставишь nginx в качестве реверс-прокси, %username%.

А еще правда в том, что с хорошей долей вероятности твой «сервер приложения» им **не будет**. То есть, это будет либо «apache + mod_passenger + django», «apache + mod_php», «unicorn + что-то на руби», «tomcat6 + мой J2EE файл». Может быть там будет даже «KVM virtual VM with pre-defined web application I definetely don't want to know anything about»

То есть у нас сформировалась «типа best practise», что сервера обычно ДВА: один смотрит наружу, быстро работает, балансирует нагрузку (если надо), кеширует 2/3 трафика ~~и это nginx~~, а второй представляет из себя собс�