Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 335
Вы просто ничего не понимаете в Node.js)
Ещё пади PHP считаете идеалом?
>>Это блядский JavaScript
вы будете гореть в аду)
Ещё пади PHP считаете идеалом?
>>Это блядский JavaScript
вы будете гореть в аду)
Ааа, вы не знаете про Теда. Ну тогда поперевожу ещё. Кстати, у вас контраргументы есть?
Я не знаю. Хочу еще… Не ждать терпения не хватит пойду читать что за чувак такой. Приятно что есть и люди которые не ведутся на хайп вокруг асинхронных фреймворков
А чем так плохи асинхронные фреймворки?
Нет, я понимаю что и на них при желании найдется тест «с резбой». Но синхронные, типа PHP, тут явно не в выигрышной ситуации.
И кстати асинхронные фреймворки не вчера появились. Это только вокруг Ноды крику много. И что странно он частенько подогревается Microsoft-ом. Любопытно в чем тут у них интерес?
Нет, я понимаю что и на них при желании найдется тест «с резбой». Но синхронные, типа PHP, тут явно не в выигрышной ситуации.
И кстати асинхронные фреймворки не вчера появились. Это только вокруг Ноды крику много. И что странно он частенько подогревается Microsoft-ом. Любопытно в чем тут у них интерес?
Плохи? Сами по себе ничем. Я например активно экспериментирую с tornado и gevent (Twisted для мутантов) и результатами доволен, хотя подводные камни тоже встречаются. Плоха шумиха вокруг них развернутая — волшебная палочка которая сделает всем вам хорошо и бесплатно. Собственно статья про то и написана, ну и ощущения от северного js у меня схожие с автором.
Как показывает практика (моя и не только) — без шума не взлетит. Это лет 10 тому назад можно было написать полезную программу и стать известным за пол года. Сейчас интенсивность фонового шума в интернете такова, что напиши ты хоть серебрянную пулю, если хотя бы ты сам не приложишь все усилия чтобы поднять вокруг своего решения максимально шума — о нем никто и никогда не узнает.
В этом кстати история практически всех успешных решений и новинок последних лет. Они небыли лучшими, и, часто даже небыли первыми. Они просто были самыми шумными. Жаль что так происходит, но такова жизнь…
В этом кстати история практически всех успешных решений и новинок последних лет. Они небыли лучшими, и, часто даже небыли первыми. Они просто были самыми шумными. Жаль что так происходит, но такова жизнь…
Да бросте Вы, совершенно очевидно, чего автор не понял. Об этом говорит пример с фиббоначи, как бы вы не старались, как бы не параллелили, если у вас одно ядро — Вы можете хоть миллион тредов наплодить, но быстрее всего задача будет решена последовательным выполнением, как в ноде, треды принесут лишь оверхэд, а если ядер несколько — нужно поднимать несколько инстансов ноды. Под неблокирующей архитектурой понимается лишь неблокирование ввода вывода, про CPU никто не говорит.
Быстрее для этого клиента не будет, а для другого — будет, т.к. он не будет ждать в очереди, пока «насильник с фибоначи» отпустит сервер.
> Но синхронные, типа PHP, тут явно не в выигрышной ситуации.
Возможно, но есть асинхронные PHP фреймворки, которые очень порадовали производительностью.
Возможно, но есть асинхронные PHP фреймворки, которые очень порадовали производительностью.
Узнал. Хорошо пишет. Мне кажется было бы еще интересно перевести Tornado vs Twisted и I Can't Wait for NoSQL to Die, правда боюсь что тот кто это тут опубликует — без кармы останется быстро.
Второй как раз давно хочу перевести, всё руки не доходили. А этот пост совсем за живое задел, потому и.
Вижу что перевод — но думаю взгяды переводчика в какой то степени отражает)
Могу и с контраргументами
function fibonacci(n) {
if (n < 2)
return 1;
else
return fibonacci(n-2) + fibonacci(n-1);
}
Для ресурсоемких операций — отдельный поток. Но таких в вебе вообще то мало очень. В большинстве случаев мы ждем либо диск, либо ответ от базы данных, либо ответ от другого сервера… Так что фибоначи можно считать в отдельном потоке и выводить всем готовый закэшированный результат. Что намного сложнее сделать в случае CGI — там придется для каждого пользователя считать его отдельно. Или записывать на диск… или в базу… или ещё как.
Про философию UNIX — херня. Нельзя жить вечно с философией прошлого тысячелетия. Это же IT)
Создавать HTTP сервер на ходу — очень удобно. Зато PHP — идеальный пример философии юникс? 100500 функций — каждая из которых делает свою задачу. При этом никакого порядка ни в названиях, ни в порядке переменных, ни в возвращаемых результатах.
Ну а про блядский Javascrpt — кто вас и автора заставляет писать так?
Могу и с контраргументами
function fibonacci(n) {
if (n < 2)
return 1;
else
return fibonacci(n-2) + fibonacci(n-1);
}
Для ресурсоемких операций — отдельный поток. Но таких в вебе вообще то мало очень. В большинстве случаев мы ждем либо диск, либо ответ от базы данных, либо ответ от другого сервера… Так что фибоначи можно считать в отдельном потоке и выводить всем готовый закэшированный результат. Что намного сложнее сделать в случае CGI — там придется для каждого пользователя считать его отдельно. Или записывать на диск… или в базу… или ещё как.
Про философию UNIX — херня. Нельзя жить вечно с философией прошлого тысячелетия. Это же IT)
Создавать HTTP сервер на ходу — очень удобно. Зато PHP — идеальный пример философии юникс? 100500 функций — каждая из которых делает свою задачу. При этом никакого порядка ни в названиях, ни в порядке переменных, ни в возвращаемых результатах.
Ну а про блядский Javascrpt — кто вас и автора заставляет писать так?
Философию вы зря обижаете. Кирпичные дома прочнее и теплее панельных, и соседей не так слышно. А то, что технология древняя… работает же!
К PHP вы тоже совершенно зря прицепились, хотя он действительно вполне себе unix way, хотя бы в части работы в качестве CGI. А названия функций… издержки быстрого роста и тяжкое наследие. Более того, сейчас мне уже кажется, что фразу про Расмуса стоило бы перевести как «вы превзошли даже...»
Давайте говорить о Node, а не тыкать пальцем, что «вон у них тоже всё плохо».
К PHP вы тоже совершенно зря прицепились, хотя он действительно вполне себе unix way, хотя бы в части работы в качестве CGI. А названия функций… издержки быстрого роста и тяжкое наследие. Более того, сейчас мне уже кажется, что фразу про Расмуса стоило бы перевести как «вы превзошли даже...»
Давайте говорить о Node, а не тыкать пальцем, что «вон у них тоже всё плохо».
Зато кирпичные строятся дольше и стоят вроде. )
PHP просто для примера. Философия может и хорошая, но автор почему решил что раз философия хорошая — то иначе и быть — иначе полная херня. Автор притянул за уши все аргументы какие смог. Мог подробно бы обсудить каждый и про бэкенд, фронтэнд сервера и про скорость вычисления Фибоначи в других языках и про запуск из консоли, но во первых мне сообщения можно писать раз в час, во вторых не гуру серверного javascript), а в третьих не вижу смысла.
Мир IT он такой. Все очень любят доказывать что то кому то. Что технология неправильная, что нужно делать так… и т.п. спорить и обсуждать это все бессмысленно — каждый решает для себя сам. Вот человек решил что node хрень — его право. Непонятно почему он пытается других убедить.
Ноду поизвращавшись можно заставить работать как CGI — вот только зачем…
PHP просто для примера. Философия может и хорошая, но автор почему решил что раз философия хорошая — то иначе и быть — иначе полная херня. Автор притянул за уши все аргументы какие смог. Мог подробно бы обсудить каждый и про бэкенд, фронтэнд сервера и про скорость вычисления Фибоначи в других языках и про запуск из консоли, но во первых мне сообщения можно писать раз в час, во вторых не гуру серверного javascript), а в третьих не вижу смысла.
Мир IT он такой. Все очень любят доказывать что то кому то. Что технология неправильная, что нужно делать так… и т.п. спорить и обсуждать это все бессмысленно — каждый решает для себя сам. Вот человек решил что node хрень — его право. Непонятно почему он пытается других убедить.
Ноду поизвращавшись можно заставить работать как CGI — вот только зачем…
Unix way был придуман, чтобы не извращаться.
Как ваша ссылка доказывает ваше утверждение? Там про нишевой продукт, а не про асинхронную general purpose серебряную пулю.
Да, ссылку не ту вставил, сорри. Хотел про nginx :)
поясню свою аналогию:
Node построен аналогично nginx, который также использует event-based модель.
Путь Unix подразумевает два варианта — отработку запросов по процессам, или в одном процессе. Использование потоков не поощряется (по сравнению с Windows way).
поясню свою аналогию:
Node построен аналогично nginx, который также использует event-based модель.
Путь Unix подразумевает два варианта — отработку запросов по процессам, или в одном процессе. Использование потоков не поощряется (по сравнению с Windows way).
Нет, если рассматривать ноуд.джиэс в качестве кирпичика для построения чего-либо. Внутреннеархитектурно — да, на троечку с плюсом.
В юникс-пути строительные элементы системы равноправны и, в лучших традициях Алана Кэя, «мощны так же, как и вся система». В наше время, к сожалению внутри юникс-пути началось деление на «кирпичики» и «имитаторы кирпичиков», причём эти имитаторы иногда путают с кирпичиками. И вставляют в кладку систем, а системы от этого пухнут и дохнут. Просто потому, что у кирпичиков есть свойство транзитивности, а у имитаторов — нет. Как правило, прикладные нишевые продукты и являются такими имитаторами. Вроде в юниксе, вроде опенсорс, вроде открытое решение — но при этом узкое, конечное и используемое только в качестве фасада, на котором можно нарастить немного плюща бизнес-логики.
Что инджайникс, что ноуд, — нишевые продукты, «улучшенные и дополненные». С тем отличием друг от друга, что первый — строительный кирпичик-прокси с включаемой функцией имитатора вебсервера, а второй — просто имитатор вебсервера с функцией убийцы эрланга или (с натяжкой) руби.
Я не люблю хейтерство во всех проявлениях (хотя сам на публику, например, иногда этим страдаю), но в данном случае склонен думать, что как нишевое решение ноуд найдёт место под солнцем, как и армию апологетов, в глазах которых классические подходы проектирования программного обеспечения себя дискредитировали в силу столкновения недостаточно опытного человека с реалиями мира. Но признавать ноуд продуктом юникс-пути — увольте, не получается.
В юникс-пути строительные элементы системы равноправны и, в лучших традициях Алана Кэя, «мощны так же, как и вся система». В наше время, к сожалению внутри юникс-пути началось деление на «кирпичики» и «имитаторы кирпичиков», причём эти имитаторы иногда путают с кирпичиками. И вставляют в кладку систем, а системы от этого пухнут и дохнут. Просто потому, что у кирпичиков есть свойство транзитивности, а у имитаторов — нет. Как правило, прикладные нишевые продукты и являются такими имитаторами. Вроде в юниксе, вроде опенсорс, вроде открытое решение — но при этом узкое, конечное и используемое только в качестве фасада, на котором можно нарастить немного плюща бизнес-логики.
Что инджайникс, что ноуд, — нишевые продукты, «улучшенные и дополненные». С тем отличием друг от друга, что первый — строительный кирпичик-прокси с включаемой функцией имитатора вебсервера, а второй — просто имитатор вебсервера с функцией убийцы эрланга или (с натяжкой) руби.
Я не люблю хейтерство во всех проявлениях (хотя сам на публику, например, иногда этим страдаю), но в данном случае склонен думать, что как нишевое решение ноуд найдёт место под солнцем, как и армию апологетов, в глазах которых классические подходы проектирования программного обеспечения себя дискредитировали в силу столкновения недостаточно опытного человека с реалиями мира. Но признавать ноуд продуктом юникс-пути — увольте, не получается.
inetd это ведь unix-way? Он же призван встроиться в цепочку от консольной программы до пользователя сети (как pipe, только на уровне сети). nginx выполняет ту же роль. Вы помните почему inetd перестал пользоваться спросом? Он вел себя точно так же как apache — плодил процессы и подгружал программы полными экземплярами. Этот подход оправдывал себя не долго и от него отказались в пользу постоянно висящих в памяти демонов. Разумеется вам никто не мешает поднять старичка из могилы для того, чтобы писать сетевые сервера на shell, но современным требованиям к коммерческим системам это уже не соответствует. То же происходит и с веб-серверами: cgi отмирает из-за низкой эффективности и на его место приходят сервера приложений, управляемые событиями. Node.js просто один из экспериментальных представителей этой эволюции. Выживет он или не пройдет естественный отбор, покажет время, но эволюционный шаг unix, начавшийся с отказа от inetd в любом случае будет сделан. И пока не ясны все особенности приходящей парадигмы, сложно прогнозировать результаты этого эксперимента. А автор, в силу юношеской категоричности, ищет грань между черным и белым в сером мире, цепляясь за свое прошлое и навязывая его восприимчивому читателю.
Я ещё раз напишу. Тред начался с того, что ноуд назвали продуктом юникс-пути. Я как можно проще изложил, почему я не считаю это корректным.
С вами целиком согласен. Смысл эволюции в многообразии форм и все эти формы имеют право на существование.
С вами целиком согласен. Смысл эволюции в многообразии форм и все эти формы имеют право на существование.
Может мы с вами по-разному понимаем одни и те же выражения, но архитектура event-driven приложений это на мой взгляд именно продукт пути, который проходит unix. С другой стороны unix-way, как понятие, означает не эволюцию, а идеологию и в этом контексте node.js не соответствует букве, хотя и пропитана духом unix-way.
Я специально отбил параграфы в своём предыдущем респонзе для разделения мыслей.
Да, не UNIX-way.
Да, event-driven и message-driven живут и у них есть будущее.
Да, не UNIX-way.
Да, event-driven и message-driven живут и у них есть будущее.
Если чесно, я вообще не понял за что вас так жестоко заминуосвали. Человек который один из немногих кто пишет статьи по программированию на хабр не достоин иметь такой низкой кармы.
Вы не вполне правы. Отдельный поток тут выгоден не всегда.
Более кошерно каждую следующую итерацию уводить в nextTick.
Более кошерно каждую следующую итерацию уводить в nextTick.
Да не, нормально будет работать — даже статья на хабре про этот метод была habrahabr.ru/blogs/nodejs/112742/. Но это какая-то «добровольная многозадачность» получается. Программист берет на себя задачи планировщика.
Разница между node.js и unix way в том, что node.js разрабатывают и используют восторженные энтузиасты, а unix way — продукт мощного инженерного подхода. Как показывает практика, 40 лет он летал, этот unix way и будет летать дальше. Быстро, эффективно и масштабируемо.
Запомните — разработчики являются ресурсом, а не самоцелью. Синтаксический сахар и лень рождают чудовищ.
Запомните — разработчики являются ресурсом, а не самоцелью. Синтаксический сахар и лень рождают чудовищ.
Пхп — это пример не юниксовой философии, а образцово-показательного бардака.
-30! За вполне сильные контраргументы в 2011! Как там в 2011?
Вот отличный контраргумент. V8 долизан до такого состояния что генерит адекватный машинный код в реалтайме. Потому по скорости там всё чудесно. Другое дело что надо им научиться напрыгивать на все ядра процессора.
Переводите. Тем более что у вас отлично выходит.
>Ну тогда поперевожу ещё
На самом деле не стóит.
На самом деле не стóит.
Для вас — не буду.
проверено на ноде, си, пхп:
нода: 5 секунд (но ёлки...331 миллион итераций… хз откуда такой алгоритм))))
си: 1 секунда
пхп: 1 минута 35 секунд (для одарённых это 95 секунд))))
исходники на СИ:
исходники на ПХП:
нода: 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;
?>
>>Ещё пади PHP считаете идеалом?
>>вы будете гореть в аду
Традиции Хабра: разговор скопипастойпереводом.
>>вы будете гореть в аду
Традиции Хабра: разговор с
Между тем тот же код в
php: 2m 31s
java: 0.891s
javascrip: 2.45s
ruby: 23.2s
as3: 2.2s
php: 2m 31s
java: 0.891s
javascrip: 2.45s
ruby: 23.2s
as3: 2.2s
-80… это жестко
Выговорился, полегчало?
ПЕРЕВОД
перевод лучше оформлять как перевод, тогда будет намного меньше вопросов
короче гон :) иконка перевода внутри топика не показывается а в списке топиков да
Что я делаю не так?
все так, просто раньше иконка перевода по-моему была и когда просматриваешь страницу топика а не только в списке
Жаль, что, благодаря интерфейсу Хабрахабра, понять, что это перевод, теперь можно только дочитав до конца и увидев мааасенькую ссылочку на оригинального автора:
Ну, или где-нибудь на третьем абзаце осознать, что это перевод, по не характерным для русского языка выражениям (ну, например, вряд ли по-русски кто-нибудь сказал бы «Это утверждение заманчиво, ободряюще и полностью, блядь, неверно.» вместо хотя бы «Это утверждение заманчиво, ободряюще и нихуя не верно.»).
Ну, или где-нибудь на третьем абзаце осознать, что это перевод, по не характерным для русского языка выражениям (ну, например, вряд ли по-русски кто-нибудь сказал бы «Это утверждение заманчиво, ободряюще и полностью, блядь, неверно.» вместо хотя бы «Это утверждение заманчиво, ободряюще и нихуя не верно.»).
Вот-вот, только хотел написать, что практически все переводы тут спокойно узнаю по нехарактерным оборотам (:
Ага, и к концу такой облом, что перевочика не польешь говном за спорную статью)
И не в лом же было переводить такое…
Уберите мат! Может в оригинале и сойдет, но не в русском.
Таков уж Тед. Иначе как «Криминальное чтиво» в переводе НТВ смотреть.
> Таков уж Тед.
Всегда поражали люди которые так говорят. Вы знакомы с Ted Dziuba лично? Поэтому называете его Ted? Или вы чувствует СВЯЗЬ между вами когда читаете его блог? Или это у вас так в Краснодаре принято? Саша, что на это скажешь?
Всегда поражали люди которые так говорят. Вы знакомы с Ted Dziuba лично? Поэтому называете его Ted? Или вы чувствует СВЯЗЬ между вами когда читаете его блог? Или это у вас так в Краснодаре принято? Саша, что на это скажешь?
Вы правы, Андрей, правильнее было бы сказать «таков уж стиль изложения Теда». Нет, я не знаю Теда лично, но давненько почитываю его опусы, да и вообще он мне интересен как личность. Я не вижу ничего страшного в том, чтобы называть людей по имени, ведь оно затем и даётся, разве нет? Более того, очень не люблю русскую традицию обращаться по имени-отчеству, мне кажется, «вы» вместо «ты», на которое мы с вами не переходили, вполне достаточно.
из песни слов не выкинешь.
E-mail, принимающий жалобы от персон, оскорбленных нецензурной лексикой:
thisisnotarealemailyouasshole@thisisnotarealemailserver.com
thisisnotarealemailyouasshole@thisisnotarealemailserver.com
Время ответа — 5 секунд.
Тед посчитал время запуска программы curl, её работы и завершения. Типичная ошибка разных тестировщиков скорости.
Числа в V8 (как и в PHP) представляются в виде машинных чисел в процессоре. По-этому математика там будет быстрой. Тест с числами Фибоначчи выбран не удачно что бы показывать тормоза. :)
Что насчёт результатов ab?
Повеселили, спасибо.
$ time curl localhost:3000
real 0m0.051s
user 0m0.012s
sys 0m0.008s
Тед посчитал время запуска программы curl, её работы и завершения. Типичная ошибка разных тестировщиков скорости.
По результатам четко видно, что большую часть времени курл провел в заблокированном состоянии (читай: ждал ответа от сервера).
Тут и без тестов понятно что пример будет тормозить. Этот пример говорит лишь о том, что его автор не понимает как работает node.js или специально вводит в заблуждение тех, кто ещё не разобрался.
Вот перевод отличной статьи.
Золотые слова из неё: «всё выполняется параллельно, за исключением вашего кода». Так что если автор, до написания этой гневной статьи думал, что этот пример выдаст ему как «меньше-чем-эксперту» нереальную производительность, то ему просто надо идти учить матчасть.
Вот перевод отличной статьи.
Золотые слова из неё: «всё выполняется параллельно, за исключением вашего кода». Так что если автор, до написания этой гневной статьи думал, что этот пример выдаст ему как «меньше-чем-эксперту» нереальную производительность, то ему просто надо идти учить матчасть.
Гневная статья? Где вы там гнев усмотрели?
> автор не понимает как работает node.js или специально вводит в заблуждение тех, кто ещё не разобрался.
node.js утверждет, что scalable решения будут писать именно такие неразобравшиеся ;)
node.js утверждет, что scalable решения будут писать именно такие неразобравшиеся ;)
Есть лозунги и есть реальность. Как только дело доходит до серьезных денег, писать будут те, кто разобрался. А что разбираться легче, так за это автору спасибо.
Между «меньше-чем-эксперты» и «серьезные деньги» — пропасть. Не говоря уже о том, что благодаря EC2 и Azure можно начинать экспериментировать с масштабируемостью и без особых денег и/или знаний.
Между «меньше-чем-эксперты» и «серьезные деньги» — пропасть.
Вас всерьез беспокоит чем увлекаются другие? Вы сокрушаетесь, что кто-то сделает не достаточно хорошо (по вашим меркам) только потому, что пошел на поводу у лукавой рекламы? Или вам никто не рассказал, что это плохо — негодовать по поводу чужих предпочтений, не совпадающих с вашими? Доводы автора о не правдивости рекламы node.js несостоятельны — порог вхождения действительно ниже и существует круг задач, где эта технология имеет свои преимущества. А то, что Тэд искал в ней универсальность викторинокса — личные проблемы Тэда и других страдающих психозом перфекционизма. Не существует самого лучшего языка или архитектуры, есть лишь удачные для определенного круга задач.
Не говоря уже о том, что благодаря EC2 и Azure можно начинать экспериментировать с масштабируемостью и без особых денег и/или знаний.
Боюсь вы введены в заблуждение. Приступая к использованию этих платформ начинать экспериментировать с масштабиемостью уже поздно — на момент запуска проекта на этих сервисах надо уже четко осознавать что и для чего ты делаешь, чтобы избегать блокировок уровня архитектуры кластера. А при этом возникают проблемы, в сравнении с которыми блокировка потока node.js покажется цветочками. (Ну запустил для вашей задачи EC2 копию вашего сервера на соседнем ip, как вы собираетесь синхронизировать копии данных? Заблокируете копии приложения обращением к одной базе данных с разных серверов? Включите зеркальную репликацию данных между серверами, создав затор обменом между копиями СУБД?). Нет, тут уже не отделаешься простыми решениями, за которые так ратует автор поста. Тут придется разбираться со всякими Hadoop и/или RabbitMQ, которые бесконечно далеки от любимого Тэдом CGI-подхода (распараллеливания процессов полными экземплярами). Вот так поэкспериментируешь с EC2 и дойдет в чем главные преимущества однопоточной архитектуры для масштабирования. И перестанете слушать всяких троллей. Может на node.js не остановитесь, но уж чем Tornado или OTP лучше любимого Тэдом django в нагруженных проектах, усвоите на зубок.
Как будто 1000 число фиббоначи хоть на каком-нибудь языке будет быстро работать =)
Так что пример нормальный.
Так что пример нормальный.
Текст из разряда «я умный, потому что бородатые дяди умные, а вы тупые, потому что вы тупые». Где умное-то в этом тексте?
1. github.com/glenjamin/node-fib — комментарий к оригинальному посту (вернее, к ссылке на него на Hacker News).
А HN, кстати, давно утвердился в качестве ведущей помойки англоязычного программерского сообщества. И ведь кому то было не лень переводить это все, с матершиной, и выкладывать на Хабр. Фантастика.
2. Дискуссии в постах вида «X — говно, а автор Y — тупица» быть никакой не может. Кому что нравится, тот и использует: Node.js, Erlang/OTP, Scala — какая разница? Райан из ничего сделал ведущий JS рантайм, и получает за это тонны навоза на голову каждую неделю. Любой, кто делал FOSS проект который использует хотя бы пара сотен человек, знает, каково это — когда куча трепачей критикуют (а часто и оскорбляют) тебя за то, что ты что-то сделал, в отличие от них.
А HN, кстати, давно утвердился в качестве ведущей помойки англоязычного программерского сообщества. И ведь кому то было не лень переводить это все, с матершиной, и выкладывать на Хабр. Фантастика.
2. Дискуссии в постах вида «X — говно, а автор Y — тупица» быть никакой не может. Кому что нравится, тот и использует: Node.js, Erlang/OTP, Scala — какая разница? Райан из ничего сделал ведущий JS рантайм, и получает за это тонны навоза на голову каждую неделю. Любой, кто делал FOSS проект который использует хотя бы пара сотен человек, знает, каково это — когда куча трепачей критикуют (а часто и оскорбляют) тебя за то, что ты что-то сделал, в отличие от них.
1. Я читаю лично Теда, о HN узнал от вас только что. Мне было не лень переводить пост, который меня задел. В комментарии на гитхабе, в секции «Why?» примерно моя позиция описана.
2. Вообще, я надеялся, что придут гуру серверного JavaScript и расскажут подробно, в чём Тед ошибается. Пока аргументов было немного, а из исходника по вашей ссылке я понял, что его писал не-менее-чем-эксперт. Тед же подошёл с позиции именно такой, и успешно доказал, что кухарка сервера писать всё ещё не может.
2. Вообще, я надеялся, что придут гуру серверного JavaScript и расскажут подробно, в чём Тед ошибается. Пока аргументов было немного, а из исходника по вашей ссылке я понял, что его писал не-менее-чем-эксперт. Тед же подошёл с позиции именно такой, и успешно доказал, что кухарка сервера писать всё ещё не может.
«сначала добейся»
А мне вот наоборот очень даже нравится node.js
По поводу блокировок:
Блокируемыми являются потоки, но не сам процесс. Читая перевод возникло ощущение того, что Тэд считает, что блокировка потока означает блокирование процесса.
По поводу блокировок:
Блокируемыми являются потоки, но не сам процесс. Читая перевод возникло ощущение того, что Тэд считает, что блокировка потока означает блокирование процесса.
А Ferrari SA Aperta очень не удобно ездить на дачу. Ferrari говно?
Статья — совершенно однобокий взгляд на node.js. Обсуждать даже смысла нет. О том как именно работает event loop и что делать со сложными математическими вычислениями написана тонна статей. Если кто-то использует node.js не понимая как он, в действительности, работает и надеясь на магическое слово «асинхронно» то это его проблема, а не Райана.
Статья — совершенно однобокий взгляд на node.js. Обсуждать даже смысла нет. О том как именно работает event loop и что делать со сложными математическими вычислениями написана тонна статей. Если кто-то использует node.js не понимая как он, в действительности, работает и надеясь на магическое слово «асинхронно» то это его проблема, а не Райана.
Серверный JS сильно отличается от клиентского, хотя заманчиво на него похож. Многие начинают использовать node.js основываясь на своих знаниях и опыту написания клиентского JS. Но почти сразу сталкиваются с проблемами, которые браузер им «прощает». Большая часть JS-скриптов на клиенте работает 1 раз при генерации страницы или основываясь на действиях пользователя (клики, ввод данных и т.п.). Речь не идёт о сложных браузерных «долго живущих» приложениях которые. Так вот. В простых клиентских скриптах не обязательно заботиться об очистке памяти, о сильно скрученных замыканиях и т.п. Т.к. страница живёт относительно не долго (и скрипт вместе с ней) то такие «косяки» не видны. И кажется что JS очень простой. Но когда такой же стиль написания применяется в серверном JS — все недочёты быстро дадут о себе знать. И в этом месте начинающие node.js разработчики делятся на 2 категории. Первые идут разбираться почему их приложение работает медленно/жрёт память/падает/грузит процессор на 100%, осознают принципы и пишут нормально. А вторые идут на форумы и льют тонны говна на Райена, JS и «всех этих фанатиков».
Мне кажется что это уляжется только когда все осознают что JS это не «почти как на пэхэпэ но проще и есть свой сервер», а довольно сложный язык программирования, явно сложнее PHP (PHP тоже многое «прощает» из за того что скрипт живёт не долго и синхронно писать легче), который требует глубокого понимания принципов работы, принципов асинхронности и т.д.
Серверный JS не для домохозяек.
Мне кажется что это уляжется только когда все осознают что JS это не «почти как на пэхэпэ но проще и есть свой сервер», а довольно сложный язык программирования, явно сложнее PHP (PHP тоже многое «прощает» из за того что скрипт живёт не долго и синхронно писать легче), который требует глубокого понимания принципов работы, принципов асинхронности и т.д.
Серверный JS не для домохозяек.
… но от маркетинга никуда не деться.
Все лозунги Node.JS про простоту разработки нужно отсчитывать от уровня самого Райана :)
Если бы node.js продали с такими обещаниями, то можно было бы подать на Райана в суд, но он бесплатен и распространяется как есть. А так, это просто краткое описание принципов работы node.js. Любой адекватный разработчик понимает что «nothing blocks» это не волшебство, а «почти ничего не блокируется». В любом случае — лить говно на чей-либо труд таких объёмов, основываясь только на нескольких строчках главной страницы, приводя примеры, которые заведомо будут тормозить — это обычный троллинг. Таких примеров можно привести миллион: айфоном плохо забивать гвозди, молотком плохо звонить.
Райану — огромное спаисбо за работу.
Горе-разоблачителям — вкусной кормёшки.
Райану — огромное спаисбо за работу.
Горе-разоблачителям — вкусной кормёшки.
А теперь вопрос зачем на этом писать? Для io-bound как пишут ниже? Для этого можно спокойно взять java.
Тут только что написали, что server side javaScript отличается от client side. Что по сути выливается в разные парадигмы программирования.
> объекты не нужно сериализовать/десериализовать
Нужно. Потому что JSON-JSON'ом, но eval при этом никуда не девается
Нужно. Потому что JSON-JSON'ом, но eval при этом никуда не девается
Строго говоря, никуда не девается синтаксический анализ; но eval для него не обязательно нужен.
Во-первых, есть скрипты наподобиеjson_sans_eval и JSON-js, способные невозбранно анализировать JSON, не прибегая к eval.
Во-вторых, даже и они не требуются, потому что в современных браузерах есть быстрые методы JSON.parseи JSON.stringify — есть они, понятное дело, и в движке Node.js, основанном на V8.
Во-первых, есть скрипты наподобие
Во-вторых, даже и они не требуются, потому что в современных браузерах есть быстрые методы JSON.parse
ну мне например, кажется заманчивым, что мне можно одни и те же алгоритмы проверок, как на клиенте, так и на сервере использовать для небольшой игрушки на html5, исходя из принципа «сначала сделать клиент и протестить клиент, а потом перенести часть критичного кода на сервер»
Тоже самое можно спросить, а зачем писать на Java, если можно на node.js? Всё зависит от конкретной задачи, конкретного разработчика, его опыта и привычек. Плохую программу и хорошую программу можно написать на любом языке.
Хотя бы по той причине, что не надо ломать себе мозг той самой серверной реализацией.
Одно дело когда у вас разные языки. А другое дело когда язык один, а подходы разные. И вы на дню по несколько раз переключаетесь туда сюда.
Джаваскрипт динамический и слабо типизированный. Он по определению будет медленнее джавы. Насколько — это уже зависит от паттернов использования и изощрённости движка.
По моему язык здесь не причем, а виновата асинхронная модель программирования. На JavaScript можно и удобно писать код в синхронном стиле используя RingoJS или мой проект Common Node. Если интересно, то вот моя презентация с RejectJS в Берлине на прошлой неделе.
Спасибо за перевод, очень экспрессивно. Сам думал перевести, но вчитался, и понял, что не буду.
По уму — автор неправ. Гораздо интереснее и точнее вот это: habrahabr.ru/blogs/nodejs/127696/
По уму — автор неправ. Гораздо интереснее и точнее вот это: habrahabr.ru/blogs/nodejs/127696/
Да, аналогично unicorn или nginx, есть и такая магия.
Для ростоты есть библиотеки типа github.com/kriszyp/multi-node
Для ростоты есть библиотеки типа github.com/kriszyp/multi-node
Какой-то бессмысленный текст — автор показал, что рассчет числа Фибоначи займет 5 секунд? А что, если он напишет его рассчет и запустит в CGI-сервере, он отработает быстрее?
Есть определенная ниша, где применение событийных фреймфорков здорово помогает (типичный пример — тысячи висящих соединений с иногда происходящими на них событиями). Нахваливаемый автором юникс-вейный CGI (это ж надо было додуматься, на каждое входящее соединение стартовать по процессу!!!) в такой ситуации съест все ресурсы сервера на форк процессов. Ну вы знаете, это то же, что бывает с сервером, если после установки Апача не понизить MaxChild (который там по дефолту то ли в 200, то ли в 300 установлен). Лучше ноды тут только C++/D и подобные языки.
Так что статья ни о чем. Если вы пишете скрипты, которые работают по 5 секунд с полной загрузкой CPU, вам ничего уже не поможет.
Есть определенная ниша, где применение событийных фреймфорков здорово помогает (типичный пример — тысячи висящих соединений с иногда происходящими на них событиями). Нахваливаемый автором юникс-вейный CGI (это ж надо было додуматься, на каждое входящее соединение стартовать по процессу!!!) в такой ситуации съест все ресурсы сервера на форк процессов. Ну вы знаете, это то же, что бывает с сервером, если после установки Апача не понизить MaxChild (который там по дефолту то ли в 200, то ли в 300 установлен). Лучше ноды тут только C++/D и подобные языки.
Так что статья ни о чем. Если вы пишете скрипты, которые работают по 5 секунд с полной загрузкой CPU, вам ничего уже не поможет.
В CGI сервере, по крайней мере, этот расчёт не заблокирует accept() входящих соединений, позволит загрузить все ядра CPU параллельными запросами этого расчёта, и не помешает параллельно с медленной обработкой этих запросов быстро обрабатывать другие запросы (как CGIшные так и на статический контент).
И да, форк это тоже не решение в современных условиях, здесь я с Вами полностью согласен.
На мой взгляд суть статьи в том, что:
И да, форк это тоже не решение в современных условиях, здесь я с Вами полностью согласен.
На мой взгляд суть статьи в том, что:
- — Совмещать веб-сервер и «неблокирующие» обработчики запросов в одной нити это плохая идея.
- — Разработка неблокирующих серверных приложений это сложная задача для экспертов, а не простая для менее-чем-экспертов, как это рекламируется.
- — JavaScript не самый подходящий язык для сервера.
Лучше ноды тут Erlang, Scala, Haskell, а потом уже все остальное.
Erlang ещё быстрее чем Node.JS считает фибоначчи: lionet.livejournal.com/95346.html
Вот многие нахваливают Erlang — особенно в сравнении с Node.JS. Щас почитал немного и пока не понял — в чём его прелесть?
В концепции. Можно завести по одному потоку на каждое из нескольких десятков тысяч подключений и не опупеть.
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 — код выглядит как код, а не как лапша:
Эрланг:
www.slideshare.net/rit2010/max-lapshin-erlyvideo-v2
lionet.info/pdf/2010-lev-walkin-erlang-experience.pdf
lionet.livejournal.com/tag/erlang
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
Кажется, начинаю понимать прелесть. Правда, с другой стороны смущает, что, например, в списках вроде как нельзя обратиться к, скажем, второму элементу списка, или ещё что-то вроде этого… А так же иммутабельность.
> в списках вроде как нельзя обратиться к, скажем, второму элементу списка
lists:nth([1,2,3,4,5], 2)
> А так же иммутабельность
К ней быстро привыкаешь. Да и обращаться ко второму элементу списка даже и не вспомню, когда приходилось. И иммутабельность, и набор типов данных приводят к другим алгоритмам работы с ними.
lists:nth([1,2,3,4,5], 2)
> А так же иммутабельность
К ней быстро привыкаешь. Да и обращаться ко второму элементу списка даже и не вспомню, когда приходилось. И иммутабельность, и набор типов данных приводят к другим алгоритмам работы с ними.
Догадываюсь :) Не очень сложно переучиваться то? Что хорошего посоветуете почитать?
Несложно. По наблюдениям некоторых товарищей, продакшн код вполне получается писать через 2 недели изучения. Из почитать, можно начать с Learn You Some Erlang for Great Good!. Лично я учил по Erlang Programming. Ну а потом уже можно и OTP in Action.
Причём " Learn You Some Erlang for Great Good!" стоит читать ровно до того момента, как эрланг перестанет казаться совсем уж инопланетным. Потом «Erlang and OTP in Action» гораздо лучше — кроме языка (который, в сущности, прост и, честно говоря, мог бы быть заменён на другой язык без особых потерь) показывается самое важное — использование инфраструктуры OTP, которая и даёт основные преимущества.
Ещё раз подчеркну: суть — не в эрланге как таковом, и его изучение — это только верзушка айсберга. Суть в OTP.
Ещё раз подчеркну: суть — не в эрланге как таковом, и его изучение — это только верзушка айсберга. Суть в OTP.
Про язык вам уже выше сказали, но основная фишка в другом — это предельно тщательно продуманная платформа, прошедшая проверку огнём, водой и медными трубами. Практически на любую архитектурную проблему, с которой вы столкнётесь, вы найдёте хорошее идиоматичное решение в рамках фреймворка, без прикручивания сторонних костылей — от конфигурирования и деплоймента до обновления. Сравнить это можно разве что с Java EE — больше я решений подобного уровня не видел. Но в OTP всё это делается куда как понятнее и читабельнее.
> Это утверждение заманчиво, ободряюще и полностью, блядь, неверно.
Я бы за это предложение Вам руку пожал!
Я бы за это предложение Вам руку пожал!
Это чистый троллинг в стиле Теда Дзюбы. Он специально пишет так, чтобы те, кто мог оскорбиться, оскорбились и уронили планку. Статью перевёл оттого, что боль в жопе никогда не мешала мне трезво мыслить. Аргументация в статье есть, и, повторюсь, основной наезд в ней — на маркетинг в стиле «кухарка сможет писать быстрые сервера, потому что ничего не блокируется». Этот подход в корне неверен, и мы уже видели, к чему он приводит, на примере PHP, только там похожий тезис повторяли фанатики, а здесь — сам создатель инструмента. А если он так утверждает, он либо нагло лжёт с целью заработать медаль «за создание лекарства от всех болезней», либо недальновиден и не понимает, к чему могут привести подобные заявления. Это мы, опять же, видели на примере PHP, в который очень быстро влилось множество кухарок, а через год миллионы людей начали его хаять за то, что на нём можно писать говнокод.
Пожалуйста, покажите, какие именно ответы я проигнорировал: у Теда комментариев на сайте нет, здесь по делу минимум. Пойду почитаю HN, на который мне показали перед сном.
Пожалуйста, покажите, какие именно ответы я проигнорировал: у Теда комментариев на сайте нет, здесь по делу минимум. Пойду почитаю HN, на который мне показали перед сном.
За публикацию здесь этого троллинга можно было бы к вам претензий не предъявлять. Но вы в качестве собственной позиции высказываете троллистские акценты и это уже достойно порицания. Текст основан на, мягко говоря, притянутых за уши аргументах:
— Ах вы обманули нас словами «неспециалисты смогут писать». Нет такой области компьютерной инженерии, где всё пишут специалисты. Послушайте что говорят бухгалтера про разработчиков желтой программы, про банк-клиенты. Посмотрите на множество убожеских сайтов. Ужас, правда? То же самое творится у строителей, педагогов, медиков… Один специалист на 50 ничтожеств. Таков наш мир и наивно полагать, что загнобив одного выскочку за то, что он пообещал слишком красиво, вы измените мир к лучшему. Перфекционизм — болезнь и вам с Тэдом не плохо бы от нее вылечиться перед тем, как писать для публики.
— Блокирование потока это якобы проблема неблокирующего фреймворка. Это, блядь, проблема процессора, который исполняет одну программу одним потоком. Это не ошибка проектирования, а логическая основа программирования. Наезжать а это всё равно, что критиковать ускорение свободного падения. Не умеешь обходить блокировки — пиши под cgi, пусть эта проблема переляжет на плечи админа.
— Идеология UNIX не имеет к написанию веб-приложения никакого отношения. CGI давно доказал свою несостоятельность для серьезных проектов. Использовать Nginx в качестве http-сервера никто не мешает. И причитать по этому поводу совершенно не конструктивно. Чистый троллинг на пустом месте.
— Ах вы обманули нас словами «неспециалисты смогут писать». Нет такой области компьютерной инженерии, где всё пишут специалисты. Послушайте что говорят бухгалтера про разработчиков желтой программы, про банк-клиенты. Посмотрите на множество убожеских сайтов. Ужас, правда? То же самое творится у строителей, педагогов, медиков… Один специалист на 50 ничтожеств. Таков наш мир и наивно полагать, что загнобив одного выскочку за то, что он пообещал слишком красиво, вы измените мир к лучшему. Перфекционизм — болезнь и вам с Тэдом не плохо бы от нее вылечиться перед тем, как писать для публики.
— Блокирование потока это якобы проблема неблокирующего фреймворка. Это, блядь, проблема процессора, который исполняет одну программу одним потоком. Это не ошибка проектирования, а логическая основа программирования. Наезжать а это всё равно, что критиковать ускорение свободного падения. Не умеешь обходить блокировки — пиши под cgi, пусть эта проблема переляжет на плечи админа.
— Идеология UNIX не имеет к написанию веб-приложения никакого отношения. CGI давно доказал свою несостоятельность для серьезных проектов. Использовать Nginx в качестве http-сервера никто не мешает. И причитать по этому поводу совершенно не конструктивно. Чистый троллинг на пустом месте.
Tornado умеет асинхронно отдавать данные, не блокируя других клиентов. Так что проблемы с Фибоначчи там просто нет. Думаю, что и в Node.js сделать такое несложно, если уже не сделано. Статья интересная, но многовато ругательств.
И что же интересного в статье? Срыв покровов что фибончаи заблокируют поток? Как будто пацаны этого и так не знают. Что кому-то не нравится JavaScript? Что какой-то чувак не будет писать на Node.JS? Хоть бы одну интересную проблему обозначили, а то выглядит так как будто автор прочитал статью на википедии перед сном и пошел срывать покровы. Даже пассаж про веб сервера странный, как будто nginx не цепляют повсеместно перед той или иной динамикой.
То, что даёт определённую пищу для размышлений. Любая статья, отрицательно ориентированная к некоему продукту, какой бы однобокой и лживой ни была — всегда полезна.
Чтобы вменяемо отдавать статику, реврайтить URL и «прочие фантастические штуки», Node.js необходим nginx или что-то подобное. Другое дело, что Node не предназначен для писания CMS, а менее-чем-эксперты, которых своею политикой притянул Райан, пытаются совать его куда ни попадя, не задумываясь, ведь им же сказали, что это идеальное решение.
Ровно такая же ситуация с noSQL, чему вы удивляетесь.
Я не слишком большой спец во всех технологиях, но если мы пишем что-нибудь высоконагруженное на python, ruby, java нам не нужен nginx для статики?
FastCGI.
То есть перед python, ruby, java нам нужен FastCGI сервер вроде nginx, как и для Node.js?
Вы таки не поверите, перед perl, php, python (за остальные говорить не буду) нужен веб-сервер! Fast он будет или просто CGI — неважно, интерпретатор не берёт на себя работу веб-сервера.
Мне просто непонятно почему веб-сервер перед PHP — это хорошо, а веб сервер перед node — это плохо (разница только в интерфейсе HTTP/CGI). Другое дело что для своих задач веб сервер node можно использовать как standalone с высокой степенью крутости (ну и да, на CMS-ках смысла может и не быть).
И это не мешало появлению HTTP-серверов написанных на perl и python. Те же разработчики tornado хоть и пишут, что на продакшне у них стоит nginx, внедрили в свой фреймворк и настоящий http-сервер. Я не вижу в этом разнообразии ничего плохого, хотя nginx ставлю и перед apache тоже.
Ну и на PHP тоже вебсерверы есть. Но разве не лучше отдать эту задачу «настоящему» серверу?
Другое дело, что Node не предназначен для писания CMS, а менее-чем-эксперты, которых своею политикой притянул Райан, пытаются совать его куда ни попадя, не задумываясь, ведь им же сказали, что это идеальное решение.
По той же логике Nikon виноват, что большинство хозяев цифрозеркалок снимает в режиме Auto. Как посмел Nikon сказать, что фотографировать может быть проще, чем в начале века? Калашников виноват, что 98% пуль летят мимо цели? Наверно вы за то, чтобы допускать к программированию только обладателей диплома? Когда до вас дойдет, что мир не совершенен? Нет такого профессионального инструмента, которым не пользовались бы не по назначению и так будет впредь. На PHP, хоть я его и не праздную, было написано немало хороших, профессиональных программ. И на Java-Scala-Erlang не смотря на более высокий порог вхождения написано немало фигни. Не надо сокрушаться о вселенной. Просто пишите свой код настолько качественно, насколько можете и это почти всё, что можете сделать вы. Не заплевывать технологию только за то, что туда привлекают начинающих, а реально делать качественный код и популяризировать профессиональные подходы к программированию.
Тед приводит доказательства блокирования потока процессорными вычислениями (не воспользуются менее-чем-эксперты тиками, нет), а не блокирования сервера отдачей данных клиенту.
Я как-то не обратил внимания, думал речь идёт об отзывчивости сервера. А тут вона как, внезапные срывы покровов, 2-й курс универа!
Какой ужас-то :) Поток блокируется. Приложение на потоки для того и разделяют, чтобы при блокировании одного, не блокировались остальные. Это суть потоков. Ожидать, что никакой из них никогда не заблокируется бессмысленно. Иначе начерта они нужны, можно всё тогда синхронно лабать.
Почитайте сайт Node. «Nothing blocks» сложно воспринимать иначе, чем «ничего не блокируется». Автор не зря начинает статью с объяснения, почему эти утверждения — откровенная ложь.
Автор придирается к словам ради красивого троллинга и не более. С таким же успехом я могу, например, начать исходить слюной по поводу того, что на сайте Mozilla написано «Простой и лаконичный интерфейс позволяет освоить программу за несколько минут.»
И я такой заряжаю пост «Крах UI Mozilla. Блядская система addonoв» и тому подобное, на полном серьёзе пытаясь доказать что за несколько минут программу освоить невозможно.
(Надеюсь я не спалил идею для поста...)
И я такой заряжаю пост «Крах UI Mozilla. Блядская система addonoв» и тому подобное, на полном серьёзе пытаясь доказать что за несколько минут программу освоить невозможно.
(Надеюсь я не спалил идею для поста...)
У него манера такая. На самом деле, обычно он пишет вполне дельные вещи, в общем случае сводящиеся к фразе «В последнее время появилось очень много нового, быстро ставшего модным. Необходимости думать головой это не отменило, не будьте идиотами».
Ну так это не дельная вещь, а банальность. Если бы эта идея была бы хоть как-то аргументирована, было бы интереснее.
Эту банальность забыло 8 человек из 10. Поэтому мы имеем HTML5-приложения в мобильных телефонах. Тот самый HTML5, в на любую задачу есть два параллельных и никак не взаимодействующих решения. Поэтому мы имеем джаваскрипт в качестве единственного браузерного языка вместо байткода или подхода NaCL. Поэтому мы долго имели Apache + mod_php на подавляющем большинстве сайтов. Поэтому мы имеем фанатиков разнообразных подходов — будь то ООП, ФП, TDD или Agile, кричащих, что они нашли серебряную пулю. Вне IT мы имеем истерию против ГМО и молитвы на всё натуральное (я тут вообще недавно видел рекламу какой-то косметики со строкой «не содержит химических веществ»).
Нет уж, напоминание о том, что надо думать головой никогда не лишне.
Нет уж, напоминание о том, что надо думать головой никогда не лишне.
Все описанные ужасы (Apache + mod_php, html5, js повсюду и т. д.) как раз и привели к тому, что Вы можете сидеть на хабре и ворчать в своё удовльствие. Без энтузиастов, осваивающих всё новое, мы бы до сих пор без штанов за мамонтами бегали.
Думать головой, конечно, надо, только вот переведённый текст этому отнюдь не способствует — он попросту глуп.
Думать головой, конечно, надо, только вот переведённый текст этому отнюдь не способствует — он попросту глуп.
Если говорить конкретно обо мне — то хабр я не сичтаю венцом прогресса, и ворчать в ньюсах мне гораздо удобнее.
Что касается текста — это он ещё мало обругал человека, пытающегося в рекламе своего продукта врать, что масштабируемость — это легко, когда никакой лёгости там и близко нет.
Кто хочет лёгкую масштабируемость — пусть берёт эрланг, он простой на самом деле. Только там тоже думать понадобится — хотя бы о том, чтобы лишние потоки данных не гонять между разными машинами.
Что касается текста — это он ещё мало обругал человека, пытающегося в рекламе своего продукта врать, что масштабируемость — это легко, когда никакой лёгости там и близко нет.
Кто хочет лёгкую масштабируемость — пусть берёт эрланг, он простой на самом деле. Только там тоже думать понадобится — хотя бы о том, чтобы лишние потоки данных не гонять между разными машинами.
Чёрт, а я уже почти поверил, что хотя бы в Эрланге думать не надо будет. Облом…
А вы ничего не путаете? Например отсутствие I/O блокировок с масштабируемостью? Или мы с вами разную рекламу видели?
А вы ничего не путаете? Например отсутствие I/O блокировок с масштабируемостью? Или мы с вами разную рекламу видели?
А вы ничего не путаете? Например отсутствие I/O блокировок с масштабируемостью? Или мы с вами разную рекламу видели?
Я только что читал его пост про NoSQL. Все его аргументы сводятся к тому, что раз реальный бизнес пользуется SQL, значит NoSQL это фигня. Вы тоже разделяете такую логику?
Torando точно так же блокируется процессорным вычислением, автор просто не понимает принципа асинхронных фреймворков и их применения.
Вероятнее всего автор просто искусно тролит.
Автор всё прекрасно понимает. Он делает вид, что он менее-чем-эксперт, берёт пример из документации, пишет в него свой функционал (разве не так поступают начинающие?) и получает результаты прямо противоположные заявленным, прекрасно доказывая, что вся маркетинговая шелуха — чистая ложь и всё не так просто, как заявлено автором. Ну а unix way — это любимая тема автора, и я с ним во многом согласен.
Почему ложь? Почему автор ставит знак равно между «не блокируется» и «выполняется мгновенно блеать»? Или фибоначчи должны были посчитаться за минус 0.1 микросекунды из-за неблокирования? Нет. Ну так в чем проблема? Автор объясняет что даже неблокирующиеся программы требуют время на выполнение? Тогда не хватает ещё объяснения что они ещё и память требуют. Он бы тогда создал массив гигов на 10 и кричал что ноджс говно, потому что на его старом ноуте с 256 мегами оперативы всё тормозит.
Он не ставит знак равно. Он говорит, что CPU-bound программы — это тоже блокирующие программы.
Теперь читаем внимательно:
Сколько из «менее-чем-экспертов» способны понять, что выделенное выше относится к I/O и только к I/O?
На сайтe Node.js сказано:
В Node практически нет функций, напрямую выполняющих операции ввода-вывода, так что процесс никогда не блокируется. Из-за того, что ничего не блокируется, менее-чем-эксперты могут разрабатывать быстрые системы.
Сколько из «менее-чем-экспертов» способны понять, что выделенное выше относится к I/O и только к I/O?
И ещё одно — вторую претензию автора тоже не стоит забывать — а состоит она, напомню, в том, что нод — плохой комбайн. С одной стороны, в нём лишний раз реализован HTTP-сервер (вместо, к примеру, на порядок более простого FastCGI-сервера), а с другой — этот сервер примитивен, что всё равно заставляет держать какой-нибудь nginx. При этом администрирование сервера и модификация программной логики поневоле будут свалены в кучу.
Tornado в этом плане от Node.JS ничем не отличается.
BREAKING NEWS: фибоначи блокируют поток!
Автор, конечно, пишет хуергу, с которой даже спорить нет смысла, поскольку его аргументация просто несостоятельна. Впрочем выше в камментах всё уже написали.
НО
Вы отлично перевели текст. Переводите хорошие тексты дальше, пожалуйста :)
НО
Вы отлично перевели текст. Переводите хорошие тексты дальше, пожалуйста :)
Автор — знатный наркоман.
> 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 в веб-сервере ЩИТО ВООБЩЕ ВЫ ТАМ ЧТО СЕБЕ В ВЕНУ КОЛЕТЕ?
> 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 в веб-сервере ЩИТО ВООБЩЕ ВЫ ТАМ ЧТО СЕБЕ В ВЕНУ КОЛЕТЕ?
Надо отметить, что стиль изложения просто отличный.
Единственное, что я почерпнул из этой статьи: «Боль в жопе непременно появится, если засунуть туда грабли». И не поспоришь ведь. Берегите здоровье — осторожнее с граблями, куда попало не суйте.
Технологии разные нужны, технологии разные важны) Оставим проблемы приложений/серверов node.js тем, кто эти проблемы создает. Не нужно устраивать крестовые походы. Если технология стоящая — она выживет и многие недостатки ее будут устренены, если нет — она канет в лету. Время все покажет! Зачем холивары? Ты программист PHP и не хочешь переходить на node.js — какие проблемы? Не переходи! Лучшая технология для тебя — та, которой ТЫ владеешь, тонкости и ньюансы которой ТЫ знаешь и понимаешь НА ГЛУБОКОМ УРОВНЕ, когда ты с ними сталкивался и их прочувствовал, когда твое понимание технологии выстрадано, а не просто изучено. А что до ограничений… любая технология имеет свои плюсы, и свои минусы.
Прочитав, хочется спросить — дядя Тед, ты дурак? Хотя понятно, на самом деле, что не дурак, а тролль.
Любому разработчику очевидно, что аргументированно спорить с этим набросом на вентилятор нет никакого смысла. Но исключительно из уважения к труду переводчика:
1. Ах, Нода тратит CPU — ВСЁ тратит CPU. Ежу понятно, что любой код исполняется на CPU, а не в квантовом мультиверсе. Если дядя Тед знает хоть одну технологию проограммирования, не тратящую вычислительные ресурсы — мы его внимательно выслушаем. Но несмотря на то, что всё тратит процессорное время, это время — самый дешёвый из имеющихся ресурсов. Заставить веб-сервер упереться в процессор ОЧЕНЬ сложно. Он гораздо раньше упрётся в диски, в сеть, в БД… Исключение блокировок диска, сети, БД и т. п. позволяет использовать CPU максимально эффективно. Это и называется «не блокировать поток исполнения» — потому что поток исполнения не останавливается и не ждёт внешних ресурсов. А то что при написании таких «неблокирующих» программ всё равно надо думать головой — это никто не отменял. Нода сама по себе от написания цикла while(true) {} не защитит. Как и PHP, Java и кто угодно ещё.
2. Ах, Нода не юникс-вей, ой-вей. Ни в одной (ещё раз: ни в одной) реально работающей системе невозможно обойтись одним уровнем обработки запросов. На любом более-менее посещаемом сайте вначале стоит Nginx или что-то вроде, а потом стоит бэкенд, обрабатывающий динамику. Даже если бэкенд сам по себе умеет обрабатывать внешний HTTP (как апач, например), Nginx, как в том анекдоте про папу Вовочки и быка, просто сделает это лучше. Нода — одна из компонент для построения многокомпонентной системы, не более. А реальные системы НЕ БЫВАЮТ однокомпонентными. И это не «ещё один уровень мониторинга», а ещё один уровень функциональности и надёжности.
3. Любить или не любить JavaScript — вопрос исключительно вкусовой.
4. Использовать или не использовать Node.js — тоже.
Любому разработчику очевидно, что аргументированно спорить с этим набросом на вентилятор нет никакого смысла. Но исключительно из уважения к труду переводчика:
1. Ах, Нода тратит CPU — ВСЁ тратит CPU. Ежу понятно, что любой код исполняется на CPU, а не в квантовом мультиверсе. Если дядя Тед знает хоть одну технологию проограммирования, не тратящую вычислительные ресурсы — мы его внимательно выслушаем. Но несмотря на то, что всё тратит процессорное время, это время — самый дешёвый из имеющихся ресурсов. Заставить веб-сервер упереться в процессор ОЧЕНЬ сложно. Он гораздо раньше упрётся в диски, в сеть, в БД… Исключение блокировок диска, сети, БД и т. п. позволяет использовать CPU максимально эффективно. Это и называется «не блокировать поток исполнения» — потому что поток исполнения не останавливается и не ждёт внешних ресурсов. А то что при написании таких «неблокирующих» программ всё равно надо думать головой — это никто не отменял. Нода сама по себе от написания цикла while(true) {} не защитит. Как и PHP, Java и кто угодно ещё.
2. Ах, Нода не юникс-вей, ой-вей. Ни в одной (ещё раз: ни в одной) реально работающей системе невозможно обойтись одним уровнем обработки запросов. На любом более-менее посещаемом сайте вначале стоит Nginx или что-то вроде, а потом стоит бэкенд, обрабатывающий динамику. Даже если бэкенд сам по себе умеет обрабатывать внешний HTTP (как апач, например), Nginx, как в том анекдоте про папу Вовочки и быка, просто сделает это лучше. Нода — одна из компонент для построения многокомпонентной системы, не более. А реальные системы НЕ БЫВАЮТ однокомпонентными. И это не «ещё один уровень мониторинга», а ещё один уровень функциональности и надёжности.
3. Любить или не любить JavaScript — вопрос исключительно вкусовой.
4. Использовать или не использовать Node.js — тоже.
От while(true) {} защитит Erlang. У него ничего не сломается от такого.
Пост не про Erlang, а про «не совместимые с жизнью» проблемы node.js
Я предлагаю альтернативу проблемам node.js, так что мой коммент в тему.
А я пользуюсь Tornado, а не node.js. Вы считаете мне тоже надо написать о его отличиях, даже если это будет офтопом?
Вообще-то да. Но отличий в Tornado от Node.JS практически нет — те же грабли, вид сбоку. Вот сравнение Erlang'овского веб-сервера и Tornado:
lionet.livejournal.com/42016.html
lionet.livejournal.com/42016.html
Видите ли, в PHP тоже ничего глобально не сломается — просто процесс будет грохнут апачем через заданный таймаут. Но это же не значит, что так и надо писать.
Вы не ощущали как тормозит сервер, у которого Apache + mod_php так размножились в памяти, что ушли в swap? А такое легко случается с синхронными приложениями при высокой нагрузке. Тогда как асинхронные всего-лишь могут выпасть по таймауту при переполнении запросами. То есть система останется стабильной и обслужит максимум запросов максимально используя ресурсы. Node.js на мой взгляд не лучший представитель этой архитектуры, но то, что пишет автор — просто бред.
По первому пункту хотелось бы поделиться с теми, кто не читал «C# via CLR» Рихтера, небольшим отрывком про потребление CPU.
Перезалейте, пжлст, статью Райана Дала куда-нибудь. У меня длинный белый лист открывается.
Вот. Там тоже есть с чем поспорить, кстати.
Благодарю.
Что-то у него общего есть с кодерами из suckless.org только он, похоже, ещё и отрицает существование понятия «внутреннее качество», а suckless напротив, считают разработчика первым и самым главным пользователем.
К топику:
> люди, использующие его, инфицируют других людей, не умеющих думать самостоятельно, пока, в конце концов, каждый встречающийся мне мудак не начинает читать проповеди
Легко применимо к любой новой технологии, разработанной в корпорации с хорошими маркетоидами, умеющими раздувать из идей тридцатилетней давности *новые* баззворды.
Что-то у него общего есть с кодерами из suckless.org только он, похоже, ещё и отрицает существование понятия «внутреннее качество», а suckless напротив, считают разработчика первым и самым главным пользователем.
К топику:
> люди, использующие его, инфицируют других людей, не умеющих думать самостоятельно, пока, в конце концов, каждый встречающийся мне мудак не начинает читать проповеди
Легко применимо к любой новой технологии, разработанной в корпорации с хорошими маркетоидами, умеющими раздувать из идей тридцатилетней давности *новые* баззворды.
Стано что никто не удивился алгоритму подсчета чисел фибоначи, капитально вызывающий рекурсию и считающий хрен знает что…
Считает он вполне себе числа Фибоначчи, самым простым методом. И для удивляющихся есть комментарий про замкнутое решение. Это классический синтетический тест.
Вот странно, у меня на нескольких языках, влкючая JS, уходит в рекурсию
Так это рекурсия и есть. Почитайте подробнее про числа Фибоначчи.
Возможно ли такое что ядро V8 дало отлуп рекурсии через 5 секунд (как в браузерах)?
Мда уж. Автор нашёл слабое место v9, и показал как плохо сервер работает, используя это слабое место. А то что если заставить nodejs отдавать статический контент, даже если он будет на лету генерироваться с помощью шаблонизатора, и при этом получить производительность порядка 10000 запросов в секунду, про это мы не говорим, ага.
Переводчику спасибо, узнал что бывают такие истерички.
Переводчику спасибо, узнал что бывают такие истерички.
лень искать пруф, но сысоев(автор nginx) говорил node.js не потянет 8k hello world'ов
не выдаст нода вам столько rps. да еще и скорее всего cpu usage будет 100% для ядра, на котором запущена.
afaik, про sendfile(2) она не в курсе.
afaik, про sendfile(2) она не в курсе.
Что я делаю не так?
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)
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)
Характеристики тестовой машины в студию, пожалуйста.
да 20000 запросов маловато, переделал с 1 000 000 запросов — результат тот же.
Document Length: 12 bytes
Ооох… вы невнимательно прочитали мой ответ. речь шла о 10k rps на статическом контенте.
Вы померили отдачу хелловорлда, что в реальной жизни никому неинтересно.
Рассказываю, как мерить правильно:
создаем файлики на 1к, 2к, 4к, 8к и запускаем ab2 меняя concurrency ( -c ключ) измеряя rps на отдаче этих файликов.
Ооох… вы невнимательно прочитали мой ответ. речь шла о 10k rps на статическом контенте.
Вы померили отдачу хелловорлда, что в реальной жизни никому неинтересно.
Рассказываю, как мерить правильно:
создаем файлики на 1к, 2к, 4к, 8к и запускаем ab2 меняя concurrency ( -c ключ) измеряя rps на отдаче этих файликов.
Мне оказалось или вы предлагаете отдавать статику через node.js?
это Disasm предлагает статику раздавать. И не вижу ничего плохого в раздаче статики через node.js (ведь мы же претендуем на полноценный server side? )
Вы широким жестом отдаете v8 заниматься работой, для которой написан nginx? Вам это не кажется неоправданным пижонством?
я предложил рассмотреть самый простой случай. в реальной жизни это может быть не отдача 1 файла, а «разобрать GET-запрос, в зависимости от параметров выбрать первый файл с которого отдавать и смещение относительно его начала, после чего отдать цепочку файлов клиенту» (т.е. сделать нечто вроде cat part0 > file && cat part1 >> file && cat part2 >> file… ).
И тут возникает дилемма: либо писать модуль для nginx, либо писать что-то свое.
В приведенном мной примере логики немного, а когда с начальными/конечными параметрами определились, надо просто дергать sendfile(2). я выбрал gevent(и на текущий момент упираюсь либо в диски, либо в сеть).
Я предложил потестировать одну из лимитирующих производительность частей — отдачу с диска фрагмента клиенту. А тестить отдачу 12 байт клиенту — весьма сомнительный бенч.
И тут возникает дилемма: либо писать модуль для nginx, либо писать что-то свое.
В приведенном мной примере логики немного, а когда с начальными/конечными параметрами определились, надо просто дергать sendfile(2). я выбрал gevent(и на текущий момент упираюсь либо в диски, либо в сеть).
Я предложил потестировать одну из лимитирующих производительность частей — отдачу с диска фрагмента клиенту. А тестить отдачу 12 байт клиенту — весьма сомнительный бенч.
Прошу прощения, что лезу в ваши личные предпочтения относительно архитектуры приложения, но в вашем гипотетическом случае я бы не стал серверу приложений давать больше работы, чем ему нужно — разобрал запрос, сделал редирект на нужный файл и дальше nginx, возможно даже на другом сервере или на связке серверов отдает эти файлы.
И много ли людей используют такое решение? Статику всегда отдает фронтенд сервер, в то время как app-сервер занимается тем, чем он должен заниматься. Если так интересно, то могу провести желанные вами тесты.
да, тесты интересны. и статика, она ведь разная бывает. например, live-трансляция, когда всем клиентам отдаются одни и те же данные(фактически, разновидность чата), а на ноде почти поголовно предлагают писать чаты.
В статье ноду трэшат cpu-bound задачей. Так давайте возьмём io-bound, на которые так хорошо ложится event loop: раздача всем клиентам одинаковых данных.
PS: я эту задачу для себя решил: 19k клиентов в онлайне, 2Гбит/с исходящего трафика(у меня пока нет 10GE для тестов).
В статье ноду трэшат cpu-bound задачей. Так давайте возьмём io-bound, на которые так хорошо ложится event loop: раздача всем клиентам одинаковых данных.
PS: я эту задачу для себя решил: 19k клиентов в онлайне, 2Гбит/с исходящего трафика(у меня пока нет 10GE для тестов).
> и статика, она ведь разная бывает.
> live-трансляция
Статика такая статика.
> live-трансляция
Статика такая статика.
для вашего успокоения: представьте, что это с диска раздаётся ;)
Нет, я не буду писать erlyvideo на node.js. Хотя бы потому, что уже есть готовый production-ready продукт.
erlyvideo — это такой комбайн. я говорю о более простой задаче. Выше я привёл цифры. не думаю, что для ноды это вызовет какие-то проблемы.
Как бы быстро перешли от disk-io к network-io и опять используем node.js вместе продукта который уже довольно таки развит (nginx). Если бы мне надо было раздавать файлы постоянно, то я бы использовал node.js только как роутер не говоря уже про кэш в оперативной.
А если так хочется гонять числа фибоначи, то всегда можно соорудить очередь с воркерами.
Довольно странное занятие вы нашли, пытаетесь убедить человека который знает, что серебряной пули не существует в том, что ее не существует…
А если так хочется гонять числа фибоначи, то всегда можно соорудить очередь с воркерами.
Довольно странное занятие вы нашли, пытаетесь убедить человека который знает, что серебряной пули не существует в том, что ее не существует…
опять nginx. ну хорошо. покажите мне пример, как на nginx в рамках _ОДНОГО_ http-запроса отдать клиенту файлы file0.part и file1.part
и где нода у вас будет как роутер.
http-сервер в node.js/gevent/tornado/twisted/eventmachine позволяет делать всё что угодно в процессе обработки запроса и встроить любую логику в обработку запроса на любом этапе
(вот опять же, попробуйте в nginx после завершения передачи файла клиенту выставить ключ в memcached, что файл отдан клиенту целиком).
и где нода у вас будет как роутер.
http-сервер в node.js/gevent/tornado/twisted/eventmachine позволяет делать всё что угодно в процессе обработки запроса и встроить любую логику в обработку запроса на любом этапе
(вот опять же, попробуйте в nginx после завершения передачи файла клиенту выставить ключ в memcached, что файл отдан клиенту целиком).
Ну тогда это уже не статика. И тут совсем другой разговор. В _этой_ ветке речь шла про статику, про разные части разных файлов в один http запрос это вы с masterbo говорили. Ну раздавайте через node.js/любой другой инструмент который подходит (хотя лично я не могу придумать когда это такое потребуется, но ладно)
а про переход 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)
это не призыв использовать такое в реальной жизни без особой необходимости.
я не пытаюсь вас убедить в отсутствии серебряной пули. вы предлагаете соорудить на nginx заведомо нерабочую конструкцию.
я знаю, что nginx прекрасно отдаёт статику(как и динамику через разные fastcgi/uwsgi), я знаю про X-Accel-Redirect и там где надо использую и, вообще, всячески за использование nginx агитирую.
Но когда вам нужна кастомная обработка запроса(например, сделать seek по файлу на значение из параметра offset) вы приходите к написанию модуля для nginx.
Идея посмотреть как нода раздает файлы:
1)проста для повторения
2)достаточно наглядна
3)интересна в сравнении с аналогичными вещами(gevent/eventmachine)
это не призыв использовать такое в реальной жизни без особой необходимости.
> а про переход 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)
Уже вижу, что разница будет минимальна, попробуйте догадаться почему.
www.slideshare.net/frank06/nodejs-riak
На каком-то из первых слайдов очень хорошо показана разница.
> я не пытаюсь вас убедить в отсутствии серебряной пули. вы предлагаете соорудить на nginx заведомо нерабочую конструкцию.
Перечитайте еще раз, что я сказал. Я говорил о статике, а не о том, что вы называете статикой — соорудить в рантайме из пачки файлов один фаил это не статика.
> Но когда вам нужна кастомная обработка запроса(например, сделать seek по файлу на значение из параметра offset) вы приходите к написанию модуля для nginx.
Да, правда кроме как для раздачи mp4 (модуль уже в core есть) мне эта фича не нужна, другое дело Streaming API.
> Идея посмотреть как нода раздает файлы:
1)проста для повторения
2)достаточно наглядна
3)интересна в сравнении с аналогичными вещами(gevent/eventmachine)
Уже вижу, что разница будет минимальна, попробуйте догадаться почему.
>соорудить в рантайме из пачки файлов один фаил это не статика.
т.е. только из-за того, что 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 не подходит для этих целей, к сожалению. Этот контейнер требует предварительной обработки, прежде чем им можно будет пользоваться для стриминга.
т.е. только из-за того, что 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 не подходит для этих целей, к сожалению. Этот контейнер требует предварительной обработки, прежде чем им можно будет пользоваться для стриминга.
> т.е. только из-за того, что n файлов улетают клиенту в рамках 1 запроса — это уже не статика?
Если кол-во файлов и их расположение не известно заранее — да, это уже не будет статикой.
> mp4 не подходит для этих целей, к сожалению. Этот контейнер требует предварительной обработки, прежде чем им можно будет пользоваться для стриминга.
Конвертации в Baseline Profile? И добавлении payload? Если надо работать с видео не понимаю почему бы не использовать erlyvideo.
Если кол-во файлов и их расположение не известно заранее — да, это уже не будет статикой.
> mp4 не подходит для этих целей, к сожалению. Этот контейнер требует предварительной обработки, прежде чем им можно будет пользоваться для стриминга.
Конвертации в Baseline Profile? И добавлении payload? Если надо работать с видео не понимаю почему бы не использовать erlyvideo.
>Если кол-во файлов и их расположение не известно заранее — да, это уже не будет статикой.
Т.е. от того, что в соковыжималку мы положили сразу 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: товарищи минусующие, а по делу есть что сказать?
Т.е. от того, что в соковыжималку мы положили сразу 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: товарищи минусующие, а по делу есть что сказать?
> Т.е. от того, что в соковыжималку мы положили сразу 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 было предложено написать видеосервер на ноде и сравнить.
Я бы разделил трансляцию и сохранение не разные приложения.
Какой плохой пример. Вот, вы уже ушли от тему в сторону черных способов спора.
> как связан профиль 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 было предложено написать видеосервер на ноде и сравнить.
Я бы разделил трансляцию и сохранение не разные приложения.
Простите, но про MPEG-TS, который максимум час с отладкой — это наглая и неприкрытая ложь.
Автор в статье перечисляет прописные истины, которые узнает каждый, кто внимательно слушает «проповеди об event loop». Внезапно, у каждого инструмента есть своя область применения, в которой он наиболее эффективен, и есть задачи, на которых его использовать совершенно не нужно. nginx, например, тоже использует event loop, но никто же не скажет, что он раковая опухоль в мире веб-серверов, ибо выполняет многие типичные для веб-сервера задачи лучше thread/process-based серверов
> полный боли в жопе пост от Райана Дала
Пост, полный боли в жопе более чем этот, надо ещё поискать :)
> полный боли в жопе пост от Райана Дала
Пост, полный боли в жопе более чем этот, надо ещё поискать :)
Да ну не воспринимайте серьёзно. Автор передёргивает, гиперболизирует и издевается давнным-давно, в каждом посте. У него такой стиль, это как Лебедев, но в IT и за бугром.
обоже, этот вброс перевели на русский и началось тоже самое %-)
Егор, давай на украинский переведем :)
Хмм, комедии на украинском смешные, а украинофилы — это отличная еда.
Автор — просто тролит сообщество и этого не скрывает.
Епт, ну сюда-то зачем этот бред было переводить.
Как контраругмент: github.com/glenjamin/node-fib — быстрый Фибоначии сервер. Но вообще вся статья не в кассу.
Как контраругмент: github.com/glenjamin/node-fib — быстрый Фибоначии сервер. Но вообще вся статья не в кассу.
Перевод может и хорош, но не для Хабра. Для двача может быть или где там переводчик обитает.
Я не хочу разговаривать матом еще и на Хабре.
Я не хочу разговаривать матом еще и на Хабре.
Алгоритм, который автор использует для вычисления чисел Фибоначчи — это феерический ппц, потому что в нём шизофреническое количество повторных вычислений, и для числа пять подсчёты выглядят подобным образом:
Для подсчёта чисел Фибоначчи нужен цикл, тогда каждый член считается один раз:
И выполняется это за доли секунды!
Для подсчёта чисел Фибоначчи нужен цикл, тогда каждый член считается один раз:
<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>И выполняется это за доли секунды!
что вы все упёрлись в алгоритм, автор хотел продемонстрировать ресурсоёмкое вычисление по памяти и процу
Для вас он написал ремарку под алгоритмом.
Вы не поняли — автору как раз нужно было сделать кучу лишних вычислений, чтобы загрузить процессор.
Ему не нужны сами числа, ему нужно кулером на проце погудеть :)
Неоптимальный рекурсивный алгоритм для этого — самое оно.
Ему не нужны сами числа, ему нужно кулером на проце погудеть :)
Неоптимальный рекурсивный алгоритм для этого — самое оно.
Уважаемый takkmoil, Вы отлично справились с переводом.
Даже не будучи программистом, но кое-что в этом понимая, с удовольствием прочитал от и до — круто.
Не слушайте ханжей, смело передавайте стиль автора, даже если это требует нецензурщины. Главное — результат. Вы однозначно дали стране угля.
Даже не будучи программистом, но кое-что в этом понимая, с удовольствием прочитал от и до — круто.
Не слушайте ханжей, смело передавайте стиль автора, даже если это требует нецензурщины. Главное — результат. Вы однозначно дали стране угля.
Я утратил веру в числа фибоначи :( Я конченный человек.
Иногда кажется, что айтишники забывают зачем они нужны. Сам по себе труд — никому не нужен. Важен только результат этого труда.
Точно такой же код на Erlang выполняется в разы быстрее, чем на Node.JS:
lionet.livejournal.com/95346.html
При этом в Erlang ничего не блокируется и не трещит по швам из-за концепции независимых асинхронных потоков без общей памяти.
lionet.livejournal.com/95346.html
При этом в Erlang ничего не блокируется и не трещит по швам из-за концепции независимых асинхронных потоков без общей памяти.
Вы смотрели-то на цифры, приведенные по ссылке? 6 секунд Node.js, 24 секунды интерпретируемый erlang, 12 секунд скомпилированный erlang. И при чём тут node.js вообще, если скорость в данном случае зависит от скорости интерпретации V8…
Erlang: 6 секунд Erlang, 24 секунды интерпретируемый Erlang
Node.JS: 12 секунд Node.JS
И да, это V8.
Node.JS: 12 секунд Node.JS
И да, это V8.
Зря вы уходите в частности. Оптимальность кода V8 это отдельный вопрос. Автор же «не может жить» с тем фактом, что на его запрос комп думал 5 секунд и вернул ему ответ, хотя он (как настоящий чайник) подумал, что ответ вернятся мгновенно, а 5-секундную работу процессора, которую он обеспечил просчетом ряда фибоначчи ему заметить не удастся. Вот что надо обсуждать — автор дурак или все-таки он успешно сеет сомнения в головах людей, плохо знакомых с архитектурой компьютера?
Автор тролль, я об этом уже написал здесь lionet.livejournal.com/95346.html
Это не отменяет того, что в Node.js есть проблемы, которые решены десятилетия (!) назад в других языках.
Это не отменяет того, что в Node.js есть проблемы, которые решены десятилетия (!) назад в других языках.
Node.js не язык, а однопоточный сервер приложений на языке javascript. То, что автор указал как трагедию, не трагедия, а глупость. Он занял процессор на 5 секунд и начал негодовать, что все 5 секунд ему пришлось ждать результата. На своем любимом Django он получил бы точно такой же результат — 5 секунд ожидания. Это не проблема Node.js. Хотя в нем проблем действительно хватает.
Проблема в том, что Node.js преподносится как универсальный молоток. А это ест мозг не только девелоперам, но и бизнесу, который говорит примерно так: «мы тут начинаем новый проект, у нас будет много-много тро-ло-ло, поэтому мы хотим юзать node.js. Мы слышали, что он крутой».
И по факту получается, что на ноде девелоперы пилят нечто отдаленно напоминающее OTP/Erlang, только кривое и бажное. Спрашивается, накуя?
И по факту получается, что на ноде девелоперы пилят нечто отдаленно напоминающее OTP/Erlang, только кривое и бажное. Спрашивается, накуя?
«Пусть распустятся сто цветов, пусть откроются сто школ». Какая вам разница что кто-то будет делать свой проект на «не правильном» с вашей точки зрения фреймворке? Коснется вас, тогда и аргументируйте своему системному архитектору или инвестору, что вы собираетесь придерживаться другой школы. Рынок всё расставит по своим местам. Не досужая болтовня о том, что кто-то не прав, а конкретные проекты с конкретной выручкой. Так пусть дерзают. Повезет — разовьют эту технологию до каких-то высот, не повезет — дадут опыт набитых шишек. Всё это ценно, а неконструктивная критика — нет.
Весь пост автора сводится к
А дальше очень много эмоций и мата по поводу того, что разработчики Node.js не рассказали об этом автору.
А дальше очень много эмоций и мата по поводу того, что разработчики Node.js не рассказали об этом автору.
Ничего не имею против эрланга, но доказывать его превосходство на таком заведомо неоптимальном алгоритме — довольно странное занятие.
Я удивлен, сколько же людей не понимают, что в приведённом примере Node.js вообще не при чём. Там используется тяжелый алгоритм(ремарка не в тему), который тупо грузит CPU. А node.js — это в основном про асинхронное IO, когда вы легко можете загрузить CPU в _промежутках_ между выполнением IO.
А реальные проблемы Node.js — ограничение на 1 ГБ используемой памяти (из-за V8, но вроде собираются побороть это) и неэффективное использование ядер (нужно запускать несколько процессов Node.js).
А реальные проблемы Node.js — ограничение на 1 ГБ используемой памяти (из-за V8, но вроде собираются побороть это) и неэффективное использование ядер (нужно запускать несколько процессов Node.js).
… и лапши из коллбэков, и в обработке ошибок, и…
и еще куча всего, но эти реальные проблемы столько эмоций не поднимут, а автору надо было сильно обмануть не сведущего читателя чем-то эффектным.
Что мешает повесить глобальный обработчик?
И вообще, кода вы пишите код, то вы пишите его для того чтобы он некорректно завершался, или все же делаете хорошо продуманную программу?
Никто вас не заставляет писать на этом языке, у каждого языка плюсы и минусы, и нужно это понимать и этим пользоваться.
process.on('uncaughtException', function (e) {
try {
sys.puts('Caught exception: ' + e + ' ' + (typeof(e) === 'object' ? e.stack : ''));
} catch(e0) {}
});И вообще, кода вы пишите код, то вы пишите его для того чтобы он некорректно завершался, или все же делаете хорошо продуманную программу?
Никто вас не заставляет писать на этом языке, у каждого языка плюсы и минусы, и нужно это понимать и этим пользоваться.
Загвоздка в том, что в реальном мире случаются катастрофы. И с этим ничего не поделаешь, как бы хорошо ни продумывать.
> Никто вас не заставляет писать на этом языке
Так я и не пишу. Как правильно ответили выше, обсуждаются фатальные недостатки инструмента в контексте решаемых задач. Настолько фатальные, что на нем вообще лучше ничего не писать (в данном случае, конечно, серверного).
> Никто вас не заставляет писать на этом языке
Так я и не пишу. Как правильно ответили выше, обсуждаются фатальные недостатки инструмента в контексте решаемых задач. Настолько фатальные, что на нем вообще лучше ничего не писать (в данном случае, конечно, серверного).
В учебнике по Erlang (Erlang programming By Francesco Cesarini, Simon Thompson) есть сравнение скорости выполнения функций с хвостовой и без хвостовой рекурсии: функции с безхвостовой рекурсии выполняются намного быстрее, так как сборка мусора происходит значительно реже.
Каким боком в данной статье node.js к скорости выполения V8 рекурсивной функции… это у автора нужно спросить.
Каким боком в данной статье node.js к скорости выполения V8 рекурсивной функции… это у автора нужно спросить.
Думаю node.js на самом деле имеет свою нишу корректной применимости. Насколько я понял, ВКонтакте использует ее для системы обмена сообщениями. Из того факта, что у них очень большие нагрузки и эта штука работает следует, что не все так с ней плохо. На мой взгляд совать node.js везде также некорректно.
О уже и тут..., а группа nodejs на Google Groups уже второй день гудит от этой статьи.
Кстати, там дали ссылку на «правильное» рекурсивное решение задачки для NodeJS
Кстати, там дали ссылку на «правильное» рекурсивное решение задачки для 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);
Интересно, долго ли тема про Node.js будет самой первой на странице. Когда «ВСЕ» было темы как то чаще менялись.
Спасибо за перевод, понравилось. Интересно было почитать авторитетного рачка с форчана.
Красиво
Блин!!! Жалко последние 4еро суток без сна за которые я делал GPS трекинг для большой компании на Node (((((( Из за того что заказчик настоял на Node и никакие аргументы не брали (
Поскольку вас разочаровала статья с откровенным троллингом, что, дабы добить вас, могу посоветовать несколько статей на тему «мы все умрем». Будет весело, обещаю.
Сон =).
Видимо он так и не понял, что достаточно Create Object (COM+ или что там на эту тему в *Nix) и возможности вызова JS интерпретатора из Shell | командной строки.
Есть комментарии из будущего 2015?)
IBM проталкивает ноду в интерпайз. Назад пути уже нет :)
На самом деле, столько лет прошло. Нода развивалась всё это время. Успела получить форк и вернуть его в себя. JS становится стандартом веб-разработки, когда нам хватит JS для всего, а узкие места можно сгладить написав библиотеку/модуль на C++.
На самом деле, столько лет прошло. Нода развивалась всё это время. Успела получить форк и вернуть его в себя. JS становится стандартом веб-разработки, когда нам хватит JS для всего, а узкие места можно сгладить написав библиотеку/модуль на C++.
Мде. Даешь некропосты, однако.
В общем, тут какое дело, ребяты… С одной стороны, мне очень нравится статья, особенно про 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, а второй представляет из себя собственно веб-приложение, которое — теперь! — может быть достаточно косым. Я не уверен, что это хорошо, но это похоже так.
И по этой причине все тезисы про «нода заставляет делать свой веб-сервер» отодвигаются в сторону как невалидные. Да, заставляет. Да, это не unix-way. Нет, ничего страшного в этом нету.
А вот касаемо замеров «что дает больше оверхеда: prefork-модель или event-модель»? Так таки да, очень интересно.
Потому как да, вообще-то «асинхронность» совершенно не является чем-то заведомо хорошим и совершенно точно не является серебряной пулей.
Рассмотрим, для примера, вот какую тему.
Так вот. Мне одному кажется, что если в разных запросах файлы одинаковые, то большой разницы не будет, так как файловая система возьмет кэширование на себя и ввод/вывод будет почти мгновенным?
А вот в случае если файлы разные — то асинхронный вариант может быть медленней (!) чем синхронный из-за особенностей работы не SSD жестких дисков, так как провоцирует ситуацию, когда одновременно диск читает из двух разных мест одновременно?
Пожалуй, запилю-ка я про это отдельную статью
В общем, тут какое дело, ребяты… С одной стороны, мне очень нравится статья, особенно про 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 трафика
И по этой причине все тезисы про «нода заставляет делать свой веб-сервер» отодвигаются в сторону как невалидные. Да, заставляет. Да, это не unix-way. Нет, ничего страшного в этом нету.
А вот касаемо замеров «что дает больше оверхеда: prefork-модель или event-модель»? Так таки да, очень интересно.
Потому как да, вообще-то «асинхронность» совершенно не является чем-то заведомо хорошим и совершенно точно не является серебряной пулей.
Рассмотрим, для примера, вот какую тему.
// SYNC
function read() {
var f = fs.readFileSync('/tmp/bigfile.txt');
return f;
}
// ASYNC
function read(done){
var f = fs.readFile('/tmp/bigfile.txt')
.then((result) => {done(result)});
} // я знаю, что с ошибками написал, неважно
Так вот. Мне одному кажется, что если в разных запросах файлы одинаковые, то большой разницы не будет, так как файловая система возьмет кэширование на себя и ввод/вывод будет почти мгновенным?
А вот в случае если файлы разные — то асинхронный вариант может быть медленней (!) чем синхронный из-за особенностей работы не SSD жестких дисков, так как провоцирует ситуацию, когда одновременно диск читает из двух разных мест одновременно?
Пожалуй, запилю-ка я про это отдельную статью
Забавно читать это из 2021-го :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Node.js — раковая опухоль