Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 173
А никто не сравнивал асинхронную архитектуру на JS и PHP? Скорость разработки, сложность отладки и поддержки, скорость выполнения?
Скорость разработки — ниже. Ибо просто особенности описанного процесса, и ни только ассинхронного, делают процесс разработки и отладки сложней. Но как только вы «войдете» в этот процесс, уже не будет сложностей. Я также хочу дополнить автора, в том, что Node перезагружается практически мгновенно. Если ее использовать скажем с Forever то для пользователя падение вашего сервера будет практически не заметен.
А еще, важный момент, Node это не просто язык программирование, ни аналог PHP, или другого серверного языка. Это симбиоз HTTP сервера и серверного языка программирования. Вы сами будете писать на языке высокого уровня маршруты сайта. Вы будете сами определять какие ресурсы и как кешировать.
А еще, важный момент, Node это не просто язык программирование, ни аналог PHP, или другого серверного языка. Это симбиоз HTTP сервера и серверного языка программирования. Вы сами будете писать на языке высокого уровня маршруты сайта. Вы будете сами определять какие ресурсы и как кешировать.
Node это не просто язык программирование
Вот именно, давайте изначально не будем сравнивать пчел с мёдом. ЯП vs. application-сервером и фреймворк.
Вы сами будете писать на языке высокого уровня маршруты сайта. Вы будете сами определять какие ресурсы и как кешировать.
Все это можно делать на любом языке программирования.
Вот именно, давайте изначально не будем сравнивать пчел с мёдом. ЯП vs. application-сервером и фреймворк.
Вы сами будете писать на языке высокого уровня маршруты сайта. Вы будете сами определять какие ресурсы и как кешировать.
Все это можно делать на любом языке программирования.
Ни холивара ради, поясните мне, как вы в стандартной связке Linux + Apach + Php + MySQL проверите, является ли текущим запросом CSS или Изображение или еще что то, если в Php (5 — 5.4) такие запросы просто не приходят? Их Apache отдает самостоятельно. Иначе зачем он нужен вообще?
Как в Php написать такое?
app.is('an image', function(req) {
return 0 == req.headers['content-type'].indexOf('image');
});
app.post('/image/upload', function(req, res, next) {
if (req.is('an image')) {
// выполняем определенные действия
} else {
next();
}
});
Может Вы что то другое имели ввиду?
Как в Php написать такое?
app.is('an image', function(req) {
return 0 == req.headers['content-type'].indexOf('image');
});
app.post('/image/upload', function(req, res, next) {
if (req.is('an image')) {
// выполняем определенные действия
} else {
next();
}
});
Может Вы что то другое имели ввиду?
PHP CGI + Sockets (fsockopen). Это я в защиту Vbart.
На любом языке программирования, который умеет работать с сетью, можно написать веб сервер.
На любом языке программирования, который умеет работать с сетью, можно написать веб сервер.
Знаете почему они не доходят до PHP? Потому что это эффективно, админ всё правильно настроил. Вы можете настроить apache/nginx — чтобы все запросы передавались на бэкенд, если вам это необходимо. Не вижу никаких проблем. То же самое касается и Node.js.
Похоже вы меня не поняли. Я имел в виду сравнение асинхронной архитектуры на JS (nodejs) и асинхронной архитектуры на PHP (phpdaemon).
Я проводил. По состоянию на более чем год назад — phpdaemon проигрывал очень сильно, причем по всем параметрам.
Документация phpdaemon не соответствовала актуальному api настолько что примеры из неё отказывались запускаться, установка требовала танцев с бубном. По потреблению памяти / скорости работы у даймона тоже все было плохо. Цифры точно не помню, но было что-то вроде 300мб даймон против 7мб ноды, на простейшей задаче.
Ну и чисто эстетитечески — phpdaemon оставляет ощущение костылей. Коими в общем и является.
Документация phpdaemon не соответствовала актуальному api настолько что примеры из неё отказывались запускаться, установка требовала танцев с бубном. По потреблению памяти / скорости работы у даймона тоже все было плохо. Цифры точно не помню, но было что-то вроде 300мб даймон против 7мб ноды, на простейшей задаче.
Ну и чисто эстетитечески — phpdaemon оставляет ощущение костылей. Коими в общем и является.
Иногда встречаются вопросы, почему приходится писать «спагетти-код» на Node.js, постоянно вкладывая друг в друга callback'и, когда на PHP все идет четко последовательно? Ведь алгоритм и там и там один и тот же.
Ответ на этот вопрос предельно прост. Потому, что это JavaScript. Асинхронность к этому более-менее ортогональна. Существуют разные подходы к написанию асинхронного кода. И существуют мощные, развитые асинхронные фреймворки, удобные, простые, хорошо продуманные, как то Twisted или Tornado.
Node.js != асинхронный подход
Node.js == много пиара
Используется JavaScript успешно в программировании интерфейсов в браузере — замечательно. Но неужели для серверного программирования сложно выучить более подходящий язык?
Полностью поддерживаю позицию по вопросу node.js. Просто страшно становится, когда в дискуссии на тему производительности различных платформ, в качестве основного аргумента в сторону node,js используют понятие асинхронности…
P. S. Свои истоки асинхронная модель берет от автоматов Мура/Мили. Или было еще что-то пораньше?
P. S. Свои истоки асинхронная модель берет от автоматов Мура/Мили. Или было еще что-то пораньше?
В питоне, кстати, помимо именно фреймворков облегчающих работу с асинхронным IO есть целые рантаймы скрывающие асинхронное IO: gevent, eventlet, greenlet.
Хотя им не все доверяют.
Хотя им не все доверяют.
Разумеется, еще и uGreen — замечательная штука, сам пользовался.
а что такого (не такого) в языке? Он разве как-то заточен? Язык это просто язык. Питон также не предназначался для веба никогда
Наверное имеется в виду, что возможности других языков позволяют при асинхронной работе использовать как callback, которые тоже есть в Торнадо, так и например генераторы — www.tornadoweb.org/documentation/gen.html
Второе позволяет сделать код более похожим на синхронный, отличие в одном лишь ключевом слове yield.
В JS я не знаю способа выйти из функции и потом вернуться в нее в ту же точку
Второе позволяет сделать код более похожим на синхронный, отличие в одном лишь ключевом слове yield.
В JS я не знаю способа выйти из функции и потом вернуться в нее в ту же точку
Питон также не предназначался для веба никогда.Это замечание справедливо и его можно ещё усилить: а вот JavaScript предназначался для веба изначально.
Если кто-то пропустил, то можно прямо сейчас посмотреть асинхронный фреймворк на php, называющийся phpDaemon. Если запустить его в один воркер, то получится в точности однопоточный nodejs. Так что любители синтаксиса php могут опробовать асинхронность прямо сейчас, не переучиваясь на js.
Кстати говоря, phpDaemon также весьма шустр.
Кстати говоря (часть 2): асинхронный код на php очень сильно отличается от «обычного» php-кода. «Вроде функции те же, а чё написано не понятно».
Кстати говоря, phpDaemon также весьма шустр.
Кстати говоря (часть 2): асинхронный код на php очень сильно отличается от «обычного» php-кода. «Вроде функции те же, а чё написано не понятно».
phpDaemon практически не имеет документации, пиара, и кроме того, порог вхождения из "обычного Js" в "Ноду" гораздо ниже, чем с "обычный php"->"phpDaemon". Я вот не тупой, а почти день убил на эту штуку чтобы посмотреть. Пока не пользую, оставил самописного демона, хотя асинхронные запросы к БД влекут :)
Поэтому посмотреть «прямо сейчас» проблематично =/
Поэтому посмотреть «прямо сейчас» проблематично =/
Там же есть примеры, да и по сути всё это не настолько сложно.
Да уж поставить его куда как сложнее, чем поставить Node.js
phpDaemon сырой и без танцев его заведёт только хороший *nix админ. При том, что Node.js ставится за пару команд.
Это мой опыт. Документации практически нет, инструкции — пара штук, 1-2 года свежести. Кстати, проект живой, я подписан на рассылку. Поэтому описанные инструкции уже местами устарели. Хотя в мэйллисте автор проекта phpDaemon и другие помогают решать задачи, отвечает на вопросы.
Т.е. phpDaemon работает, и из коробки может быть лучше чем Node.js ибо он изначально многопоточный. Но реально порог вхождения нужно снижать, чтобы набрать популярность.
И популярность это хорошо, это быстрый рост проекта.
А я сейчас на пороге выбора, и хотя phpDaemon у меня завёлся, я сейчас думаю, на чём начинать проект. И склоняюсь к Node, как к более удобному в технической поддержке. Да и люблю я JavaScript.
phpDaemon сырой и без танцев его заведёт только хороший *nix админ. При том, что Node.js ставится за пару команд.
Это мой опыт. Документации практически нет, инструкции — пара штук, 1-2 года свежести. Кстати, проект живой, я подписан на рассылку. Поэтому описанные инструкции уже местами устарели. Хотя в мэйллисте автор проекта phpDaemon и другие помогают решать задачи, отвечает на вопросы.
Т.е. phpDaemon работает, и из коробки может быть лучше чем Node.js ибо он изначально многопоточный. Но реально порог вхождения нужно снижать, чтобы набрать популярность.
И популярность это хорошо, это быстрый рост проекта.
А я сейчас на пороге выбора, и хотя phpDaemon у меня завёлся, я сейчас думаю, на чём начинать проект. И склоняюсь к Node, как к более удобному в технической поддержке. Да и люблю я JavaScript.
За что человека минусовали? Самому в скором времени нужен будет сервер для вебсокетов, а ещё не определился с платформой.
phpDaemon сырой и без танцев его заведёт только хороший *nix админ. При том,Прибавлю, что в Windows можно начать «установку» Node.js вообще одним движением пальца, жмякнув мышóю по гиперссылкечто Node.js ставится за пару команд.
(Здесь слово «установка» я взял в кавычки, потому что настолько простую последовательность действий
Лет 8 назад я писал однопоточный демон на PHP с помощью socket_select() (мне нужен был клиент для iChat с постоянным коннектом, реализующий несложную текстовую игру). Работало это достаточно шустро и надёжно, перегружал этого демона не чаще раза в неделю. Я и подумать не мог, что именно эта технология через несколько лет станет популярной и начнёт набирать обороты.
Кстати написать нечто подобное с нуля может любой средний программер на PHP, это может быть полезно, например, для того, чтобы «на берегу» разобрать все тонкости работы с таким демоном. Как Вы понимаете, в nodejs по сути реализовано то же самое, просто больше библиотек и пафоса.
Кстати написать нечто подобное с нуля может любой средний программер на PHP, это может быть полезно, например, для того, чтобы «на берегу» разобрать все тонкости работы с таким демоном. Как Вы понимаете, в nodejs по сути реализовано то же самое, просто больше библиотек и пафоса.
Самый быстрый в мире веб-сервер nginx.
Самый быстрый среди самых используемых. Существует масса самописных и форков, которые работают несколько быстрее.
Лучшее решение, которое позволяет нам полностью загрузить процессор полезной работой это переход к архитектуре, использующей неблокирующие операции.
Глупости. Явно быстрее было бы все хранить в ОП, использовать синхронную модель, не использовать функции для работы с файловой системой, сокетами, wait functions. Другими словами, все зависит от конкретной ситуации.
Различия асинхронной и многопоточной архитектур на примере самого ужасного из асинхронных фреймворков и продукте, к многопоточности не имеющего отношения.
А так да — статья норм.
А так да — статья норм.
Не знаю Node.js. Но он, разве, действительно на столько плох, как вы говорите? В чем тогда заключается его текущая популярность?
Буду очень благодарен за ваш комментарий по этому вопросу.
Буду очень благодарен за ваш комментарий по этому вопросу.
> Но он, разве, действительно на столько плох, как вы говорите?
Да. Потому что он — мешанина из коллбэков, без возможности утилизации SMP и всякими радостями JS типа плоского пространства имен и т.п.
> В чем тогда заключается его текущая популярность?
Hype. Причем одновременно в двух значениях — media circus и hype cycle
Да. Потому что он — мешанина из коллбэков, без возможности утилизации SMP и всякими радостями JS типа плоского пространства имен и т.п.
> В чем тогда заключается его текущая популярность?
Hype. Причем одновременно в двух значениях — media circus и hype cycle
Спасибо за ответ! Предполагаю, что понял что вы хотели сказать.
В nodejs еще есть хохмы типа раннего Rails:
— течет память? Не проблема, перезапустим сервер, он же быстро перезапускается! (в последних версиях чуть-чуть исправили ситуацию)
— нужн использовать два ядра? Запустим две VM. Нужно использовать 4 ядра? Запустим 4 VM.
Отсутсвие утечек памяти? Автоматический SMP с учетом переключения контекстов ядра и т.п.? Нет, не слышали :)
— течет память? Не проблема, перезапустим сервер, он же быстро перезапускается! (в последних версиях чуть-чуть исправили ситуацию)
— нужн использовать два ядра? Запустим две VM. Нужно использовать 4 ядра? Запустим 4 VM.
Отсутсвие утечек памяти? Автоматический SMP с учетом переключения контекстов ядра и т.п.? Нет, не слышали :)
Все ещё течет?
Год назад текло, сейчас не заметно. Можно пример кода на котором это наблюдается? Или ссылку на статью. Не хотелосб бы наступить.
По наблюдениям — основная проблема ноды на данный момент — сборщик мусора и плохая утилизация больших объемов памяти.
Год назад текло, сейчас не заметно. Можно пример кода на котором это наблюдается? Или ссылку на статью. Не хотелосб бы наступить.
По наблюдениям — основная проблема ноды на данный момент — сборщик мусора и плохая утилизация больших объемов памяти.
Слежу за багтрекером и вносимыми изменениями уже больше года — исправлений и подтверждённых багов по поводу мемликов было очень мало.
Чаще всего за мемлики принимают специфическую работу GC, который не успевает срабатывать при большой нагрузке, для борьбы с этим рекомендуется раз в несколько секунд дёргать GC руками через --expose-gc + gc(), тогда потребление памяти станет более предсказуемым.
Реальные мемлики действительно имеют место в сторонних модулях, как раз на днях напоролся в таком, казалось бы проверенном модуле, как socket.io.
Чаще всего за мемлики принимают специфическую работу GC, который не успевает срабатывать при большой нагрузке, для борьбы с этим рекомендуется раз в несколько секунд дёргать GC руками через --expose-gc + gc(), тогда потребление памяти станет более предсказуемым.
Реальные мемлики действительно имеют место в сторонних модулях, как раз на днях напоролся в таком, казалось бы проверенном модуле, как socket.io.
> Чаще всего за мемлики принимают специфическую работу GC, который не успевает срабатывать при большой нагрузке, для борьбы с этим рекомендуется раз в несколько секунд дёргать GC руками через --expose-gc + gc()
Боже какой ад. То есть это еще хуже, чем я предполагал
Боже какой ад. То есть это еще хуже, чем я предполагал
Толсто же.
Переходить на ручную сборку мусора приходится только на запредельных нагрузках, на которых в альтернативных решениях скорее всего тоже полезут специфические проблемы. Только вот там возможность ручного управления может и отсутствовать.
И если уж делать вызов gc руками — лучше делать это не раз в несколько секунд, а выбирая моменты снижения нагрузки, а если их нет — по фактической необходимости, отслеживая занятую память.
Переходить на ручную сборку мусора приходится только на запредельных нагрузках, на которых в альтернативных решениях скорее всего тоже полезут специфические проблемы. Только вот там возможность ручного управления может и отсутствовать.
И если уж делать вызов gc руками — лучше делать это не раз в несколько секунд, а выбирая моменты снижения нагрузки, а если их нет — по фактической необходимости, отслеживая занятую память.
Стандартное поведение GC — это и есть «выбирая моменты снижения нагрузки».
По наблюдениям при большом кол-ве неубранного мусора нода помимо памяти начинает ещё и процессор хавать, что оставляет ещё меньше времени для GC и это растёт как снежный ком. А минусов в вызове gc() по интервалу никаких не нашёл, он в основном отрабатывает за 1 — 2 мс, что для обычных задач не критично.
По наблюдениям при большом кол-ве неубранного мусора нода помимо памяти начинает ещё и процессор хавать, что оставляет ещё меньше времени для GC и это растёт как снежный ком. А минусов в вызове gc() по интервалу никаких не нашёл, он в основном отрабатывает за 1 — 2 мс, что для обычных задач не критично.
Мне интересно, при каких таких «запредельных» нагрузках уже приходится ставить вызов GC вручную по интервалу
http://habrahabr.ru/post/123154/
Вообще, при 20к конкурентных подключений уже можно ощутить заметный выйгрыш. Правда пока кроме синтетических тестов встречать такие ситуации не приходилось.
Вообще, при 20к конкурентных подключений уже можно ощутить заметный выйгрыш. Правда пока кроме синтетических тестов встречать такие ситуации не приходилось.
Где вы тут ад нашли, 3 строки кода на всё про всё. Что вы ещё хотите от автоматической сборки мусора, если нужно более-менее управляемое поведение — делаем руками.
Что я хочу от автоматической сборки мусора? Предсказуемость, быструю работу, отсутствие необходимости вообще ее запускать вручную
И где есть такой волшебный GC?
Даже в священном Erlang говорят и по 20мс фризы бывают: http://www.unlimitednovelty.com/2011/07/trouble-with-erlang-or-erlang-is-ghetto.html «Erlang sucks at managing memory»
Даже в священном Erlang говорят и по 20мс фризы бывают: http://www.unlimitednovelty.com/2011/07/trouble-with-erlang-or-erlang-is-ghetto.html «Erlang sucks at managing memory»
У него просто Erlang головной мозга и банальное не умение понимать того, что он не знает. У Ерлангеров это профессиональная болезнь — ненавидеть ноду. Вероятно зависть…
В ноде внезапно появился автоматический SMP? Или внятное управление иерархиями процессов? Или отслеживание ошибок в удаленных процессах? Или легковесная реализация иммутабельных данных (обязательная для внятной асинхронности)?
Нет, там нет SMP и разработчики использующие node.js действительно считают, что запуск 4VM на 4-х ядерном сервере это нормально.
> Или внятное управление иерархиями процессов?
Взял специфичную для ерланга и его процессов фичу @ выставил как аргумент
> Или легковесная реализация иммутабельных данных (обязательная для внятной асинхронности)?
Взял философию ерланга (которая только одна единственная и она правильная, прямо как Аллах, слава ему) @ выставил как аргумент
> В ноде внезапно появился автоматический SMP?
Там можно циклом for запускать воркеров по кол-во ядер, считается?
> Или внятное управление иерархиями процессов?
Взял специфичную для ерланга и его процессов фичу @ выставил как аргумент
> Или легковесная реализация иммутабельных данных (обязательная для внятной асинхронности)?
Взял философию ерланга (которая только одна единственная и она правильная, прямо как Аллах, слава ему) @ выставил как аргумент
> В ноде внезапно появился автоматический SMP?
Там можно циклом for запускать воркеров по кол-во ядер, считается?
> там нет SMP и разработчики использующие node.js действительно считают, что запуск 4VM на 4-х ядерном сервере это нормально.
То есть, я все правильно сказал.
> Взял специфичную для ерланга и его процессов фичу @ выставил как аргумент
Ничего специфичного в этом нет. Иерархии процессов в любом случае появляются рано или поздно и желательно, чтобы «ах этот мегакрутой новый самый лучший в мире асинхронный фреймворк» имел хоть какие-то возможности по управлению ими. Да хотя бы управлением четырьмя VM на 4-х ядрах
> Взял философию ерланга
Сорри. Имел в виду не иммутабельные, а неразделяемые (share nothing). Пусть будут мутабельными :)
> Там можно циклом for запускать воркеров по кол-во ядер, считается?
Нет.
То есть, я все правильно сказал.
> Взял специфичную для ерланга и его процессов фичу @ выставил как аргумент
Ничего специфичного в этом нет. Иерархии процессов в любом случае появляются рано или поздно и желательно, чтобы «ах этот мегакрутой новый самый лучший в мире асинхронный фреймворк» имел хоть какие-то возможности по управлению ими. Да хотя бы управлением четырьмя VM на 4-х ядрах
> Взял философию ерланга
Сорри. Имел в виду не иммутабельные, а неразделяемые (share nothing). Пусть будут мутабельными :)
> Там можно циклом for запускать воркеров по кол-во ядер, считается?
Нет.
> Ничего специфичного в этом нет.
Где кроме ерланга есть процессы такие как в ерланге?
> Да хотя бы управлением четырьмя VM на 4-х ядрах
Есть мастер который может останавливать, запускать новые в рантайме, а так же запускать их с произвольным кодом (по 2 VM, на 2х портах с разными задачами).
Где кроме ерланга есть процессы такие как в ерланге?
> Да хотя бы управлением четырьмя VM на 4-х ядрах
Есть мастер который может останавливать, запускать новые в рантайме, а так же запускать их с произвольным кодом (по 2 VM, на 2х портах с разными задачами).
Не кормите его. Хейтеры только этого и ждут.
> Где кроме ерланга есть процессы такие как в ерланге?
Для появления иерархии процессов нужны процессы, как в Эрланге? Нуну
> Есть мастер который может останавливать, запускать новые в рантайме, а так же запускать их с произвольным кодом
Каким образом эти VM бджут общаться между собой?
Для появления иерархии процессов нужны процессы, как в Эрланге? Нуну
> Есть мастер который может останавливать, запускать новые в рантайме, а так же запускать их с произвольным кодом
Каким образом эти VM бджут общаться между собой?
> Каким образом эти VM бджут общаться между собой?
Можно настроить pub/sub через redis или zeromq.
> Для появления иерархии процессов нужны процессы, как в Эрланге? Нуну
Для этого нужны процессы вообще. Или вы про другие процессы? Если просто надо иерархию всех вызовов и прочего — DTrace уже изобрели, добавить можно к много чему, не только node.js.
Можно настроить pub/sub через redis или zeromq.
> Для появления иерархии процессов нужны процессы, как в Эрланге? Нуну
Для этого нужны процессы вообще. Или вы про другие процессы? Если просто надо иерархию всех вызовов и прочего — DTrace уже изобрели, добавить можно к много чему, не только node.js.
> Можно настроить pub/sub через redis или zeromq.
То есть городить неведомо что на ровном месте
> Для этого нужны процессы вообще. Или вы про другие процессы?
Процессы/потоки/акторы — без разницы. Даже если архитектура строго на коллбэков, у тебя есть иерархия этих коллбэков или объектов, их содержащих.
Вон, ты не можешь даже SMP по-человечески использовать без того, чтобы не возводить вокруг ад из pub/sub и т.п.
То есть городить неведомо что на ровном месте
> Для этого нужны процессы вообще. Или вы про другие процессы?
Процессы/потоки/акторы — без разницы. Даже если архитектура строго на коллбэков, у тебя есть иерархия этих коллбэков или объектов, их содержащих.
Вон, ты не можешь даже SMP по-человечески использовать без того, чтобы не возводить вокруг ад из pub/sub и т.п.
> То есть городить неведомо что на ровном месте
Начнем с того, что VM выполняющие одни и те же функции не должны между собой общаться.
> Процессы/потоки/акторы — без разницы. Даже если архитектура строго на коллбэков, у тебя есть иерархия этих коллбэков или объектов, их содержащих.
DTrace. Я уже сказал. Зачем ты прогнозировал ту часть комментария? Я понимаю, что ерланг не умеет нормально со строками работать (они же не нужны), но ты то умеешь.
> Вон, ты не можешь даже SMP по-человечески использовать без того, чтобы не возводить вокруг ад из pub/sub и т.п.
взял философию erlang/otp @ попытался ее натянуть на node.js
Начнем с того, что VM выполняющие одни и те же функции не должны между собой общаться.
> Процессы/потоки/акторы — без разницы. Даже если архитектура строго на коллбэков, у тебя есть иерархия этих коллбэков или объектов, их содержащих.
DTrace. Я уже сказал. Зачем ты прогнозировал ту часть комментария? Я понимаю, что ерланг не умеет нормально со строками работать (они же не нужны), но ты то умеешь.
> Вон, ты не можешь даже SMP по-человечески использовать без того, чтобы не возводить вокруг ад из pub/sub и т.п.
взял философию erlang/otp @ попытался ее натянуть на node.js
> Начнем с того, что VM выполняющие одни и те же функции не должны между собой общаться.
1. Кто сказал, что они выполняют одни и те же функции?
2. Кто сказал, что VM, выполняющие одинаковую работу, не могут между собой общаться?
> DTrace. Я уже сказал. Зачем ты прогнозировал ту часть комментария?
Какое отношение DTrace имеет к организации иерархии процессов?
> взял философию erlang/otp @ попытался ее натянуть на node.js
Неверно понятая философия
1. Кто сказал, что они выполняют одни и те же функции?
2. Кто сказал, что VM, выполняющие одинаковую работу, не могут между собой общаться?
> DTrace. Я уже сказал. Зачем ты прогнозировал ту часть комментария?
Какое отношение DTrace имеет к организации иерархии процессов?
> взял философию erlang/otp @ попытался ее натянуть на node.js
Неверно понятая философия
> 2. Кто сказал, что VM, выполняющие одинаковую работу, не могут между собой общаться?
2 треда в апаче которые обрабатывают запрос клиента общаются между собой?
> Какое отношение DTrace имеет к организации иерархии процессов?
Внезапно, им можно «рисовать» иерархию процессов на сервере или внутри приложения.
> Неверно понятая философия
no shared state + message passing + erlang processes; Очевидно же ты просто берешь то, что есть в ерланге и выставляешь как плюс. Кроме как отсутствие SMP (настоящего) можешь, что-то сказать дельное? Почему у тебя анальная боль только от node.js? В Ruby тоже нет SMP, и тоже есть фрэимворк (и не один) который утилизирует паттерн «Реактор».
2 треда в апаче которые обрабатывают запрос клиента общаются между собой?
> Какое отношение DTrace имеет к организации иерархии процессов?
Внезапно, им можно «рисовать» иерархию процессов на сервере или внутри приложения.
> Неверно понятая философия
no shared state + message passing + erlang processes; Очевидно же ты просто берешь то, что есть в ерланге и выставляешь как плюс. Кроме как отсутствие SMP (настоящего) можешь, что-то сказать дельное? Почему у тебя анальная боль только от node.js? В Ruby тоже нет SMP, и тоже есть фрэимворк (и не один) который утилизирует паттерн «Реактор».
> 2 треда в апаче которые обрабатывают запрос клиента общаются между собой?
VM'ы преднахначены только для одноразовой обработки запросов от пользователя?
> Внезапно, им можно «рисовать» иерархию процессов на сервере или внутри приложения.
Я говорил о «рисаовать»?
> no shared state + message passing + erlang processes; Очевидно же ты просто берешь то, что есть в ерланге и выставляешь как плюс.
Очевидно, я беру то, что является «way to go» в создании масштабируемых распределенных прилоэений и выставляю это, как «way to go». И к Erlang'у это имеет отношение только потому, что этот путь в нем уже реализован.
> Кроме как отсутствие SMP (настоящего) можешь, что-то сказать дельное?
Дельного даже в этой подветке я уже сказал много.
VM'ы преднахначены только для одноразовой обработки запросов от пользователя?
> Внезапно, им можно «рисовать» иерархию процессов на сервере или внутри приложения.
Я говорил о «рисаовать»?
> no shared state + message passing + erlang processes; Очевидно же ты просто берешь то, что есть в ерланге и выставляешь как плюс.
Очевидно, я беру то, что является «way to go» в создании масштабируемых распределенных прилоэений и выставляю это, как «way to go». И к Erlang'у это имеет отношение только потому, что этот путь в нем уже реализован.
> Кроме как отсутствие SMP (настоящего) можешь, что-то сказать дельное?
Дельного даже в этой подветке я уже сказал много.
> VM'ы преднахначены только для одноразовой обработки запросов от пользователя?
Ты же прекрасно понял о чем я.
> Я говорил о «рисаовать»?
А что еще с ними можно сделать? Управлять реактором можно, свои события выстреливать можно, обработчики тоже можно. В случае с коллбеками ничего кроме как нарисовать ничего не получится. Хватит притягивать божественные процессы ерланга куда только можно.
Ты же прекрасно понял о чем я.
> Я говорил о «рисаовать»?
А что еще с ними можно сделать? Управлять реактором можно, свои события выстреливать можно, обработчики тоже можно. В случае с коллбеками ничего кроме как нарисовать ничего не получится. Хватит притягивать божественные процессы ерланга куда только можно.
> Ты же прекрасно понял о чем я.
Нет, не понял
> А что еще с ними можно сделать?
Я уже понял, что ты не понимаешь, что такое иерархия процессов.
Нет, не понял
> А что еще с ними можно сделать?
Я уже понял, что ты не понимаешь, что такое иерархия процессов.
Хватит тупить. Я тебе прошу, хватит тупить. Серьезно, я монитор от твоего жира не успеваю оттирать. Я понимаю, что тебе больно от того, что node.js и ruby, популярнее erlang, и то, что там сообщество нормальное и развитое и библиотеки есть и даже драйвера к базам данных (которые, согласно тебе, не нужны для настоящих приложений). Я понимаю, это очень больно, но старайся контролировать это боль, хорошо? Мне кажется ты справишься. Хватит выставлять мак-сообщество идиотами.
Ну понятно, раз аргументов нет, надо попытаться оскорбить оппонента.
1. С какого перепугу ты VM'ы node.js сравниваешь с процессами/потоками apache'а, которые одноразово выполняют запрос?
2. С какого перепугу на вопрос «как организовывать иерархию процессов/коллбэков с мониторингом и отслеживанием нештатных ситуаций» ты отвечаешь «DTrace нарисует»?
3. С какого перепугу ты считаешь что городить огород из pubsub/redis/zeromq для элементарных, по сути, задач — это нормально?
Так что тут еще вопрос, чей жир капает у тебя с монитора.
1. С какого перепугу ты VM'ы node.js сравниваешь с процессами/потоками apache'а, которые одноразово выполняют запрос?
2. С какого перепугу на вопрос «как организовывать иерархию процессов/коллбэков с мониторингом и отслеживанием нештатных ситуаций» ты отвечаешь «DTrace нарисует»?
3. С какого перепугу ты считаешь что городить огород из pubsub/redis/zeromq для элементарных, по сути, задач — это нормально?
Так что тут еще вопрос, чей жир капает у тебя с монитора.
1. Потому, что цепочка из колбэков будет обрабаывать один запрос от клиента. В этой цепочке нет смысла делать общение с другими цепочками. Связь между VM'ами на уровне сообщений от мастера к клиенту и vice versa, вполне достаточно.
2. Потому, что ты пытаешься притянуть процессы ерланга за уши. Отлеживать нештатные ситуации можно только через исключения и проверку аргумента в колбеке. Хватит притягивать ерланговские процессы.
3. Какой там огород? Я же не RabbitMQ притащил. pubsub позволит разнести VM'ы на разные сервера и сохранить связь между ними. Хватит притягивать ерланговские сообщения.
2. Потому, что ты пытаешься притянуть процессы ерланга за уши. Отлеживать нештатные ситуации можно только через исключения и проверку аргумента в колбеке. Хватит притягивать ерланговские процессы.
3. Какой там огород? Я же не RabbitMQ притащил. pubsub позволит разнести VM'ы на разные сервера и сохранить связь между ними. Хватит притягивать ерланговские сообщения.
> Потому, что цепочка из колбэков будет обрабаывать один запрос от клиента.
То есть ты хочешь сказать, что node.js ничем не отличается от, скажем, РНР? Один запрос — одна цепочка действий, всё?
> В этой цепочке нет смысла делать общение с другими цепочками.
Если ты неспособен что-то представить, не значит, что это не нужно
> Потому, что ты пытаешься притянуть процессы ерланга за уши.
Это не ответ на вопрос «зачем DTrace»
> Отлеживать нештатные ситуации можно только через исключения и проверку аргумента в колбеке.
Ну то есть недалеко ушли от С/С++ с таким же «удобством».
> Какой там огород? Я же не RabbitMQ притащил. pubsub позволит разнести VM'ы на разные сервера и сохранить связь между ними.
Ну то есть хваленая мегагиперкрутая система nodejs неспособна даже на одном компьютере внятно общаться между VM без ручного создания груды велосипедов на каких-то сторонних технологиях. Спасибо
То есть ты хочешь сказать, что node.js ничем не отличается от, скажем, РНР? Один запрос — одна цепочка действий, всё?
> В этой цепочке нет смысла делать общение с другими цепочками.
Если ты неспособен что-то представить, не значит, что это не нужно
> Потому, что ты пытаешься притянуть процессы ерланга за уши.
Это не ответ на вопрос «зачем DTrace»
> Отлеживать нештатные ситуации можно только через исключения и проверку аргумента в колбеке.
Ну то есть недалеко ушли от С/С++ с таким же «удобством».
> Какой там огород? Я же не RabbitMQ притащил. pubsub позволит разнести VM'ы на разные сервера и сохранить связь между ними.
Ну то есть хваленая мегагиперкрутая система nodejs неспособна даже на одном компьютере внятно общаться между VM без ручного создания груды велосипедов на каких-то сторонних технологиях. Спасибо
2 треда в апаче которые обрабатывают запрос клиента общаются между собой?
Если это Apache+mod_php, то php скрипты вполне могут через, например, shmem.
Если это Apache+mod_php, то php скрипты вполне могут через, например, shmem.
Но нет – для этого берется php, а общее состояние в итоге воссоздается через сериализацию, ключи, доп. библиотеки, протоколы, сокеты, сеть…
shared memory стандартный для POSIX механизм разделения данных между процессами. Для Linux ещё есть /dev/shm.
shared memory стандартный для POSIX механизм разделения данных между процессами. Для Linux ещё есть /dev/shm.
Просто на удивление(!), мало кто задумывается, какое кол-во проблем вытекает из этой пост-CGIной парадигмы.
Ну, я задумываюсь уже лет 10, а толку. Изучать Си и системное программирование, реализовывать в PHP многопоточность, при этом как-то оставляя обратную совместимость, посылать соответствующие патчи без всякой гарантии, что их примут… И всё это ради того, чтобы реализовать true FastCGI с разделением данных между всеми обработчиками запросов, когда существуют пускай не столь эффективные, но рабочие костыли.
Ну, я задумываюсь уже лет 10, а толку. Изучать Си и системное программирование, реализовывать в PHP многопоточность, при этом как-то оставляя обратную совместимость, посылать соответствующие патчи без всякой гарантии, что их примут… И всё это ради того, чтобы реализовать true FastCGI с разделением данных между всеми обработчиками запросов, когда существуют пускай не столь эффективные, но рабочие костыли.
мало кто задумывается, какое кол-во проблем вытекает из этой пост-CGIной парадигмы.Да нет — на самом деле много кто задумывается, только действуют не многие.
У меня например самописный application server, как раз с такой поддержкой FastCGI, какую вы имеете в виду (правда не для пыха, а tcl и питона) и со всеми плюшками таких серверов, как то пулы данных и потоков, очереди событий и сообщений, background processing, connection sharing и тд и тп.
И кстати навесить FastCGI на любой уже существующий application server не есть сложно — нужно просто сделать.
Просто порог вхождения для программирования на таком сервере потом «немного» выше — многие из известных мне php программистов не представляют даже какие вещи и как быстро на этом можно собирать, написав в десятки раз меньше кода.
Какой-то бред вы написали. Если VM выполняют одну и туже задачу, то они не должны обмениться ничем. Только на уровне Master -> Worker. Если же надо связать несколько разных VM с разными задачами — сообщения на zeromq первое, что приходит в голову. Люди даже на с++ общения в тредах на нем делают (дам подсказку, сеть использовать не обязательно.
Мастер поток может общаться с дочерними через worker.send(), process.on('message', function () {… }). Для вещания между всеми процессами есть хороший модуль clusterhub основанный на этом функционале. Т.е. в этом случае можно обойтись без Redis.
Он просто сейчас скажет, что ерланг может все это делать по сети из коробки, поэтому надо было действовать наперед.
> Мастер поток может общаться с дочерними через worker.send(), process.on('message', function () {… }).
Спасибо.
— Может ли дочерний поток что-то передать родителю?
— Может ли родитель отслеживать, жив ли дочерний поток и каким-то образом обрабатывать нештатные ситуации?
> Для вещания между всеми процессами есть хороший модуль clusterhub основанный на этом функционале.
Спасибо.
Из краткого описания как раз видно, что что они пытаются натянуть модель акторов/событий на node.js. Что говорится, на безрыбье…
Спасибо.
— Может ли дочерний поток что-то передать родителю?
— Может ли родитель отслеживать, жив ли дочерний поток и каким-то образом обрабатывать нештатные ситуации?
> Для вещания между всеми процессами есть хороший модуль clusterhub основанный на этом функционале.
Спасибо.
Из краткого описания как раз видно, что что они пытаются натянуть модель акторов/событий на node.js. Что говорится, на безрыбье…
> — Может ли дочерний поток что-то передать родителю?
Да может. process.send({ hello: 'master' }); передаст сообщение родителю. Он получит его в worker.on('message', function(data) { });
> — Может ли родитель отслеживать, жив ли дочерний поток и каким-то образом обрабатывать нештатные ситуации?
Да может, для этого существуют несколько событий сигнализирующих о разных этапах помирания процесса.
Да может. process.send({ hello: 'master' }); передаст сообщение родителю. Он получит его в worker.on('message', function(data) { });
> — Может ли родитель отслеживать, жив ли дочерний поток и каким-то образом обрабатывать нештатные ситуации?
Да может, для этого существуют несколько событий сигнализирующих о разных этапах помирания процесса.
Может ли дочерний поток что-то передать родителю?Да. Пример из документации по Node.js:
var cp = require('child_process');
var n = cp.fork(__dirname + '/sub.js');
n.on('message', function(m) {
console.log('PARENT got message:', m);
});
Может ли родитель отслеживать, жив ли дочерний поток?Аналогично, n.on('exit',
А я наоборот, где-то год назад сходил на мастер-класс по эрлангу к товарищу Лапшину, и понял, что сервер буду писать на node.js.
Чего вы людей в заблуждение то вводите?
Пока процесс делает блокирующий вызов он процессорное время не потребляет!
Ппц…
Пока процесс делает блокирующий вызов он процессорное время не потребляет!
Ппц…
По-моему, только в случае если где-то внутри блокирующего вызова не используются асинхронные механизмы или принудительная передача управления ядру. Если блокирующая функция написана как-то вроде (псевдокод):
то она будет потреблять процессор, если _file_read_ready() не использует асинхронные механизмы или не вызывает, скажем sleep();
file_read(file) {
_file_read_init(file);
while(!_file_read_ready(file))
{
};
return _file_read_data(file);
}
то она будет потреблять процессор, если _file_read_ready() не использует асинхронные механизмы или не вызывает, скажем sleep();
Если у вас задача — за 2мс получить данные из БД и за 2мс их обработать то единственным разумным решением будет запустить по 2 потока на ядро.
Вот если у вас под 90% времени IO — то тогда да, есть смысл сэкономить память и разгрузить планировщик OS используя «асинхронный» подход (неблокирующее IO, FSM и собственный планировщик)
Вот если у вас под 90% времени IO — то тогда да, есть смысл сэкономить память и разгрузить планировщик OS используя «асинхронный» подход (неблокирующее IO, FSM и собственный планировщик)
«Но ведь при этом мы получаем 50% простоя процессора!»
Разве мы получаем 50% простоя процессора? Ведь в это время процессор работает с БД, делает выборку, формирует ответ.
В конце концов все рассчитывается процессором. Отправив запрос на считывание файла мы забираем часть мощности процессора на загрузку файла, в этот момент получив следующий запрос, менее ресурсоемкий, процессор ведь не прекращает считывание файла он лишь также выделяет другую часть своей вычислительной мощности. А как придет этот запрос, в другом потоке или асинхронно мне кажется не имеет значение для загрузки процессора. Или я ошибаюсь?
Разве мы получаем 50% простоя процессора? Ведь в это время процессор работает с БД, делает выборку, формирует ответ.
В конце концов все рассчитывается процессором. Отправив запрос на считывание файла мы забираем часть мощности процессора на загрузку файла, в этот момент получив следующий запрос, менее ресурсоемкий, процессор ведь не прекращает считывание файла он лишь также выделяет другую часть своей вычислительной мощности. А как придет этот запрос, в другом потоке или асинхронно мне кажется не имеет значение для загрузки процессора. Или я ошибаюсь?
В конце концов все рассчитывается процессором. Отправив запрос на считывание файла мы забираем часть мощности процессора на загрузку файла
Упс, зацепил shift+enter случайно. Хотел ссылку дать в ответ на цитату: DMA
Работать с БД, делать выборку и формировать ответ может процессор на другом краю Земли (чаще, конечно, в том же датацентре, но не суть), localhost в свойствах подключения — это частный случай, да и все равно какое-то время процессор будет простаивать ожидая данных с диска или даже с памяти. не 50%, конечно, но это же пример.
с чего вы взяли, что процессор будет простаивать? что мешает ОС переключить его на выполнение другого процесса/потока? Да, смена контекста — накладные расходы, но тем не менее в многопоточной программе блокирующий ввод/вывод в одной нити не приводит к блокировке всех потоков, в отличие от однопоточной на основе epoll/kqueue, кстати.
Современные популярные ОС для ПК и серверов — это ОС с вытесняющей многозадачностью. Если у нас, скажем, 10 процессов с одинаковым приоритетом, работающих вплоть до физического ввода/вывода синхронно, то за 1 секунду все десять отработают по 0,1 секунды. ОС не знает, выполняет процессор сложные вычисления или гоняет цикл типа
while(read_port(disk) !== DATA_READY);. С точки зрения ОС процессор работает, с точки зрения пользователя — простаивает, не выполняя полезной работы, выполняя пустой цикл до наступления какого-то события 10% процессорного времени. В асинхронных же системах процесс сообщает системе, что ждёт какого-то события, и пока событие не наступит, передавать ему управление смысла нет, он «спит» и ждёт «будильника». Хотя бы в таком примитивном виде как while(read_port(disk) !== DATA_READY) { usleep(1); }
Вообще-то, в современных популярных ОС потоки, которые заснули на блокирующем сисколе, не получают своего кванта времени до тех пор, пока сискол не отработает. Никаких пустых циклов ожидания в здравом уме никто не делает, исключением из этого является спинлок.
с чего Вы взяли, что блокирующие операции ввода/вывода работают именно так, с пустым циклом? Системные вызовы реализованы несколько иначе :)
в целом статья хорошая — спасибо.
есть несколько замечаний:
В это время будет отработан другой поток. Операционная система сама распределит ресурсы! Да, есть небольшие накладные расходы. Мониторинг моего продакшен сервера показывает загрузку на все 800% всех 8- ядер.
Согласен, что «блокирующие операции — зло». Но с неблокирующими операциями есть свои подводные камни, своя оборотная сторона медали.
Предположим, что мы ждем ответа от «тяжелого запроса», в это время пришел еще один «тяжелый запрос» — мы открыли новый буфер для обработки соединения, затем новый… а первый еще не обработался… и не обработался второй… А процесс обработки всего один…
В итоге может возникнуть такая ситуация, что заполнится вся выделенная область памяти и воникнет переполнение
буфера или начнется «сокетный голод».
Конечно, если будут чередоваться тяжелые и легкие запросы, что ближе к жизни, то такой ситуации может и не возникнет… Но, дураков в жизни хватает, до сих пор нахожу в проектах «поиск по Like 2-Процента». Так что, Дурак может убить любую архитектуру, будь она многопоточная или асинхронная.
есть несколько замечаний:
На асинхронной модели построен самый быстрый в мире веб-сервер nginx.отстал от жизни — уже не самый. Но Сысоев, несомненно, внес большой вклад в развитие рунета.
При отправке запросов к БД поток начинает ожидать ответа. Пока данные не вернутся — поток никакой работы выполнять не будет. Это 2мс простоя на запрос в 4мс! Да, мы не можем сделать рендеринг страницы, не получив данные из базы. Мы обязаны ждать. Но ведь при этом мы получаем 50% простоя процессора!
В это время будет отработан другой поток. Операционная система сама распределит ресурсы! Да, есть небольшие накладные расходы. Мониторинг моего продакшен сервера показывает загрузку на все 800% всех 8- ядер.
Согласен, что «блокирующие операции — зло». Но с неблокирующими операциями есть свои подводные камни, своя оборотная сторона медали.
Предположим, что мы ждем ответа от «тяжелого запроса», в это время пришел еще один «тяжелый запрос» — мы открыли новый буфер для обработки соединения, затем новый… а первый еще не обработался… и не обработался второй… А процесс обработки всего один…
В итоге может возникнуть такая ситуация, что заполнится вся выделенная область памяти и воникнет переполнение
буфера или начнется «сокетный голод».
Конечно, если будут чередоваться тяжелые и легкие запросы, что ближе к жизни, то такой ситуации может и не возникнет… Но, дураков в жизни хватает, до сих пор нахожу в проектах «поиск по Like 2-Процента». Так что, Дурак может убить любую архитектуру, будь она многопоточная или асинхронная.
«отстал от жизни — уже не самый»
А кто и как это определеяет, кстати? Просто интересно, может я тоже отстал. =)
А кто и как это определеяет, кстати? Просто интересно, может я тоже отстал. =)
Приктика -критерий истины, в нашем случае это определяют тесты
www.monkey-project.com/benchmarks/raspberry_pi_monkey_nginx
gwan.ch/benchmark
есть и еще малые быстрые сервера, наш рунет немного зациклился на nginx
собираюсь сделать исследование и обзор
www.monkey-project.com/benchmarks/raspberry_pi_monkey_nginx
gwan.ch/benchmark
есть и еще малые быстрые сервера, наш рунет немного зациклился на nginx
собираюсь сделать исследование и обзор
Жуткий оффтоп, но:
Именно, и на практике выходит вот как.
Тесты хэлоуворлдов? Тем более от авторов конкурирущих продуктов? Не смешите.
Мы не побуликуем тесты, в которых nginx обходит всех остальных, включая перечисленных вами, только по одной простой причине: мы знаем как настраивать свой продукт, знаем его сильные и слабые стороны, знаем как из него выжать максимум. Публиковать подобные тесты, как это делают конкуренты — это опускаться до их уровня.
Nginx показывает высокий уровень производительности на большинстве задач, при этом прекрасно масштабируется, обладает богатым функционалом, имеет хорошую поддержку и активно разрабатывается. И год от года становится ещё лучше. В общем и целом — отличный выбор. Выжимание максимума rps в искусственно созданных условиях на синтетических задачах — интересно только админам локалхостов.
Есть. Но когда пишут «самый быстрый», то стоит огласить критерии, а то окажется, что самый быстрый веб-сервер побеждает в состязаниях далеких от реальных задач (как то отдать ab «Hello world»).
И хорошо. От продвижения отечественного продукта в конечном итоге выигрывает вся страна.
Приктика -критерий истины
Именно, и на практике выходит вот как.
это определяют тесты
Тесты хэлоуворлдов? Тем более от авторов конкурирущих продуктов? Не смешите.
Мы не побуликуем тесты, в которых nginx обходит всех остальных, включая перечисленных вами, только по одной простой причине: мы знаем как настраивать свой продукт, знаем его сильные и слабые стороны, знаем как из него выжать максимум. Публиковать подобные тесты, как это делают конкуренты — это опускаться до их уровня.
Nginx показывает высокий уровень производительности на большинстве задач, при этом прекрасно масштабируется, обладает богатым функционалом, имеет хорошую поддержку и активно разрабатывается. И год от года становится ещё лучше. В общем и целом — отличный выбор. Выжимание максимума rps в искусственно созданных условиях на синтетических задачах — интересно только админам локалхостов.
есть и еще малые быстрые сервера
Есть. Но когда пишут «самый быстрый», то стоит огласить критерии, а то окажется, что самый быстрый веб-сервер побеждает в состязаниях далеких от реальных задач (как то отдать ab «Hello world»).
наш рунет немного зациклился на nginx
И хорошо. От продвижения отечественного продукта в конечном итоге выигрывает вся страна.
я не вижу здесь конкуренции
Когда пользователя побуждают к отказу от одного продукта в пользу другого, проводя сравнение с помощью специально поставленных тестов — это что?
>Именно, и на практике выходит вот как.
согл, популярность набирает — это факт
>Но когда пишут «самый быстрый», то стоит огласить критерии, а то окажется, что самый быстрый веб-сервер побеждает в состязаниях далеких от реальных задач (как то отдать ab «Hello world»).
Отдача «Hello world», согласись со мной, вполне сойдет, как один из критериев.
Вообще-то, если внимательно почитать назначение, то эти сервера вовсе не предназначены для WEB порталов. У них совсем другая ниша: встраиваемые решения. У них простой функционал, а соответственно отсюда и скорость.
согл, популярность набирает — это факт
>Но когда пишут «самый быстрый», то стоит огласить критерии, а то окажется, что самый быстрый веб-сервер побеждает в состязаниях далеких от реальных задач (как то отдать ab «Hello world»).
Отдача «Hello world», согласись со мной, вполне сойдет, как один из критериев.
Вообще-то, если внимательно почитать назначение, то эти сервера вовсе не предназначены для WEB порталов. У них совсем другая ниша: встраиваемые решения. У них простой функционал, а соответственно отсюда и скорость.
Отдача «Hello world», согласись со мной, вполне сойдет, как один из критериев.
Нет, не соглашусь. Хотите отдавать «Hello world», то соберите nginx без пары десятков опций и модулей, а в конфиге напишите:
Плюс буфера потюнить под эту строчку, + accept_mutex, + лог, и т.д.
Вообще-то, если внимательно почитать назначение, то эти сервера вовсе не предназначены для WEB порталов.
Отлично, если они имеют совсем другое предназначение и никак не претендуют на область применения nginx, то зачем их сравнивают с nginx, причем в стандартной сборке?
Нет, не соглашусь. Хотите отдавать «Hello world», то соберите nginx без пары десятков опций и модулей, а в конфиге напишите:
location / {
return 200 "Hello world";
}
Плюс буфера потюнить под эту строчку, + accept_mutex, + лог, и т.д.
Вообще-то, если внимательно почитать назначение, то эти сервера вовсе не предназначены для WEB порталов.
Отлично, если они имеют совсем другое предназначение и никак не претендуют на область применения nginx, то зачем их сравнивают с nginx, причем в стандартной сборке?
а сделать тест можешь?
Могу, получу некое число rps на своей системе, оно кому-нибудь нужно? Вот тут люди 1 миллион запросов в секунду с nginx снимают.
С практической точки зрения важно, чтобы nginx не становился bottleneck-ом в той или иной реальной задаче.
С практической точки зрения важно, чтобы nginx не становился bottleneck-ом в той или иной реальной задаче.
если без холивара, то я писал специализированные WEB сервера по подсчету кликов, в 4 раза производительней nginx. (мерилось ab моего сервиса и nginx, который проксировал запросы на Сишный демон)
хотя, отчасти ты прав — в энжиниксе были подключены все дефолтные модули…
убрать их — производительность ненамного поднимется
убрать их — производительность ненамного поднимется
Самый быстрый веб-сервер — это тот, который ничего не делает. =)
Вместо Си-шного демона, я полагаю, можно было бы слепить что-нибудь на lua прямо в nginx, и вместе с luajit оно бы не сильно уступило специализированному Си-шному демону, а времени на разработку и отладку было бы потрачено в разы меньше.
ab — кстати, слишком медленная и криво-написанная утилита. Её не имеет смысл использовать для тестирования nginx-а. Я, например, наблюдал ситуации, когда с точки зрения ab rps падал при выключении access-логов. Происходила забавная штука, nginx обрабатывал запрос так быстро, что успевал уйти в epool и отдохнуть там до того, как ab присылала новый. Цифры ab часто зависят от того, насколько её паттерн работы накладывается на паттерн работы веб-сервера. Это, впрочем, верно для любого синтетического бенчмарка.Вместо Си-шного демона, я полагаю, можно было бы слепить что-нибудь на lua прямо в nginx, и вместе с luajit оно бы не сильно уступило специализированному Си-шному демону, а времени на разработку и отладку было бы потрачено в разы меньше.
Вспомнил забавный топик в рассылке:
mailman.nginx.org/pipermail/nginx/2012-April/033304.html
Человек протестировал одну и ту же конфигурацию с помощью трех разных утилит и получил в разы отличающиеся цифры, удивился. =)
mailman.nginx.org/pipermail/nginx/2012-April/033304.html
Человек протестировал одну и ту же конфигурацию с помощью трех разных утилит и получил в разы отличающиеся цифры, удивился. =)
да, знаю, есть такое…
просто я уже привые к аб :(
просто я уже привые к аб :(
Попробуй wrk, http парсер у этой штуки от nginx-а, асинхронные треды на epool/kqueue. Собирается очень просто. Имеет смысл клонировать pipeline бранч.
Тестировал как-то пару лет назад G-WAN vs nginx на weighttp, статику (но не helloworld), так вот — G-WAN порвал тогда nginx как тузик грелку. Надо бы попробовать снова (оба заметно подросли). До сих пор не переехал с nginx, в силу занятости (нужно переписать несколько модулей) и не кроссплатформенности G-WANа (есть еще одна VM под винду).
И пожалуй три (The many pitfalls of benchmarking) — простая истина в изложении разработчика Varnish.
Вы меня совсем за новичка держите:
Я специально включил «accesslog» на статику за неделю и полностью отэмулировал его на weig, со всеми плюшками, типа 304 (с if-modified-since, разрывом, релоад, и т.д.), с нескольких машин многопоточно и одновременно.
И я прекрасно знаю отличие от продакшн — даже сотня браузеров ведет себя не как тесты подобные weighttp — и естественно сперва попробовал бы G-WAN в бою — но как говорилось уже руки не доходят.
В G-WAN меня привлекают еще два момента:
1) G-WAN разрабатывался изначально почти как app-server (nginx — нет) — например c++ servlet пишется под G-WAN на ура быстро — т.е. можно прикрутить tcl, питон (любимое подставить) как реальный application server и byebye fast-cgi;
2) Для nginx я видимо так и не дождусь никогда NTLMAuthMod'а, а ниписать его под nginx4win видится мне весьма проблематично — для G-WAN это выглядит, судя по API, многим проще. Хотя не так давно они отказались от разработки под windows — кроссплатформенность мне пока что очень важна — но может быть удастся форкнуть его от предыдущих ревизий под винду.
Может вообще буду юзать сразу оба — таки да — nginx я тоже люблю и уважаю)
Я специально включил «accesslog» на статику за неделю и полностью отэмулировал его на weig, со всеми плюшками, типа 304 (с if-modified-since, разрывом, релоад, и т.д.), с нескольких машин многопоточно и одновременно.
И я прекрасно знаю отличие от продакшн — даже сотня браузеров ведет себя не как тесты подобные weighttp — и естественно сперва попробовал бы G-WAN в бою — но как говорилось уже руки не доходят.
В G-WAN меня привлекают еще два момента:
1) G-WAN разрабатывался изначально почти как app-server (nginx — нет) — например c++ servlet пишется под G-WAN на ура быстро — т.е. можно прикрутить tcl, питон (любимое подставить) как реальный application server и byebye fast-cgi;
2) Для nginx я видимо так и не дождусь никогда NTLMAuthMod'а, а ниписать его под nginx4win видится мне весьма проблематично — для G-WAN это выглядит, судя по API, многим проще. Хотя не так давно они отказались от разработки под windows — кроссплатформенность мне пока что очень важна — но может быть удастся форкнуть его от предыдущих ревизий под винду.
Может вообще буду юзать сразу оба — таки да — nginx я тоже люблю и уважаю)
github.com/yandex-load/yandex-tank
Дарю :) Пока, правда, без красивых графичков.
Дарю :) Пока, правда, без красивых графичков.
Надо будет его побенчмаркать с помощью nginx-а, быстрее он wrk или медленнее. =)
Ой, да вы прикалываетесь, этот yandex-tank вообще на Perl. Боюсь себе представить, сколько мне серверов потребуется, чтобы создать такую нагрузку, которую бы nginx с хэлоуворлдом заметил.
Сия тулза вообще главным образом для тестирования веб-приложений. Оверхэд самого веб-сервера с помощью неё измерить едва ли возможно.
Сия тулза вообще главным образом для тестирования веб-приложений. Оверхэд самого веб-сервера с помощью неё измерить едва ли возможно.
немного оффтопа:
Когда пишут «самый быстрый в мире», надо быть уверенным, что он действительно «самый быстрый в мире».
Плохо это или хорошо — это другой вопрос, но когда оказывается, что это не так, то тут уж извините…
Чувство патриотизма — это всегда хорошо. Но и зарывать голову в песок и кричать «Мы самые крутые...» как-то невяжется с делом.
Лично, я nginx-сом вполне доволен и все проекты, с которыми я работал последние 5-ть лет, крутятся на нем. Про аппач — я давно уже и забыл…
Когда пишут «самый быстрый в мире», надо быть уверенным, что он действительно «самый быстрый в мире».
Плохо это или хорошо — это другой вопрос, но когда оказывается, что это не так, то тут уж извините…
Чувство патриотизма — это всегда хорошо. Но и зарывать голову в песок и кричать «Мы самые крутые...» как-то невяжется с делом.
Лично, я nginx-сом вполне доволен и все проекты, с которыми я работал последние 5-ть лет, крутятся на нем. Про аппач — я давно уже и забыл…
Каждый скрипт работает в своем потоке. Один поток обрабатывает один запрос. Потоков у нас достаточно большое количество, медленные запросы забирают поток надолго, быстрые — обрабатываются почти мгновенно, освобождая поток для другой работы.Автор явно путает понятие потока и процесса. В случае с РНР, есть разные варианты обработки. Либо это Апач, который запускает n-е worker процессов. Либо это nginx с проксированием FastCGI на кучу запущенных процессов php-fpm, либо это лайти, c проксированием на запущенных spawn php-fcgi
В любом случае — это отдельные процессы, с отдельно выделенным адресным пространством.
В РНР нет ни каких потоков и многопоточности
В данном случае разницы между потоками и процессами никакой нету.
а что за такой данный случай?
есть понятие поток (thread) есть понятие процесс (process).
есть понятие поток (thread) есть понятие процесс (process).
Который в статье написан. С точки зрения ядра Linux, к примеру, поток — это тоже процесс, просто он имеет общее адресное пространство и общие ядерные объекты типа дескрипторов с другими процессами, входящим в тот же process group. Если не пользоваться общей памятью, не использовать общие дескрипторы, то разницы между процессом и потоком с прикладной точки зрения нету.
Общая память разве не входит в основные отличия многопоточной архитектуры от многопроцессной?
с точки зрения Unix и в частности qnx — совершенно разные понятия, которые путать нельзя
Ещё раз: я не говорю о том, что между ними нету разницы в принципе. Я утверждаю, что если каким либо образом запустить php в нескольких потоках и при этом это будут независимые интерпретаторы, и если запустить его в нескольких процессах, то нет никакой разницы при сравнении с node.js, т.к. что мультитредность, что мультипроцессность — суть не меняется, ОС одинаково будет шедулить потоки, потоки точно так же будут спать в сисколах и т.д. Слово абстракция вам знакомо?
Вы абсолютно не правы — это если php в том виде как есть запустить многопоточно, то отличий действительно будет не много.
Если же php правильно сделать multithreaded — т.е., как вам уже верно намекнули выше, с общей памятью, общеми соединениями, очередями и др. плюшками — это будет извините совсем другой коленкор.
И абстракция здесь не причем — автор сделал грубую ошибку — ему на нее указали. Просто как раз такими ляпами сбивают с пути истинного неопытных программистов:)
Не холивара ради — правды для…
Если же php правильно сделать multithreaded — т.е., как вам уже верно намекнули выше, с общей памятью, общеми соединениями, очередями и др. плюшками — это будет извините совсем другой коленкор.
И абстракция здесь не причем — автор сделал грубую ошибку — ему на нее указали. Просто как раз такими ляпами сбивают с пути истинного неопытных программистов:)
Не холивара ради — правды для…
если каким либо образом запустить php в нескольких потоках и при этом это будут независимые интерпретаторы
И зачем так извращаться? По крайней мере в Линукс, как самой популярной ОС для PHP. Суть многопоточности как раз в том что потоки не независимы, а могут шарить данные между собой меньшей ценой чем при многопроцессности.
И зачем так извращаться? По крайней мере в Линукс, как самой популярной ОС для PHP. Суть многопоточности как раз в том что потоки не независимы, а могут шарить данные между собой меньшей ценой чем при многопроцессности.
Отвечу сразу и вам, и комментатору выше.
Что такое асинхронное выполнение кода, как в node.js? Это 1 поток, который получает уведомления от ядра, и свитчит контексты задач в userland. При этом внутри ядра для получения асинхронности дискового ввода-вывода AIO в Linux, к примеру, создаются потоки, которые блокируются, а потом посылают уведомление в userland. Минусы: сложно писать. Именно про это пишет автор поста.
Многопоточное или многопроцессное приложение использует большое количество потоков/процессов (существенно больше количества ядер, сотни, а то и тысячи потоков), каждое выполняет одну задачу, а шедулятся они уже ядром. Минусы: накладные расходы на контекст свитчинг.
В любом случае будут общие очереди, соединения и т.д., но это больше относится к обвязке, непосредственно получающей запросы клиентов и ставящей их в очередь на обработку.
Что вы там хотите шарить между потоками в типичном веб-приложении мне совершенно непонятно, т.к. в большинстве своём каждый запрос не зависит от остальных, это одно из условий горизонтального масштабирования. Или вы считаете, что синхронизация доступа к одному ресурсу из нескольких потоков бесплатна?
И да, я писал сервисы на тредпуле, которые держат десятки тысяч запросов в секунду. И да, я в курсе как применять epoll вместе с конечными автоматами для написания асинхронных приложений, писал хитрые модули для nginx и смотрел, как устроена node.js. И как бороться с лишними решедулингами в сетевых приложениях тоже, кстати, знаю.
Что такое асинхронное выполнение кода, как в node.js? Это 1 поток, который получает уведомления от ядра, и свитчит контексты задач в userland. При этом внутри ядра для получения асинхронности дискового ввода-вывода AIO в Linux, к примеру, создаются потоки, которые блокируются, а потом посылают уведомление в userland. Минусы: сложно писать. Именно про это пишет автор поста.
Многопоточное или многопроцессное приложение использует большое количество потоков/процессов (существенно больше количества ядер, сотни, а то и тысячи потоков), каждое выполняет одну задачу, а шедулятся они уже ядром. Минусы: накладные расходы на контекст свитчинг.
В любом случае будут общие очереди, соединения и т.д., но это больше относится к обвязке, непосредственно получающей запросы клиентов и ставящей их в очередь на обработку.
Что вы там хотите шарить между потоками в типичном веб-приложении мне совершенно непонятно, т.к. в большинстве своём каждый запрос не зависит от остальных, это одно из условий горизонтального масштабирования. Или вы считаете, что синхронизация доступа к одному ресурсу из нескольких потоков бесплатна?
И да, я писал сервисы на тредпуле, которые держат десятки тысяч запросов в секунду. И да, я в курсе как применять epoll вместе с конечными автоматами для написания асинхронных приложений, писал хитрые модули для nginx и смотрел, как устроена node.js. И как бороться с лишними решедулингами в сетевых приложениях тоже, кстати, знаю.
Что вы там хотите шарить между потоками в типичном веб-приложении мне совершенно непонятно, т.к. в большинстве своём каждый запрос не зависит от остальных, это одно из условий горизонтального масштабирования. Или вы считаете, что синхронизация доступа к одному ресурсу из нескольких потоков бесплатна?
Read-only данные, включая собственно исходный код приложения, вернее результат его интерпретации, обработанные конфиги и т. п., что постоянно для обработчиков всех запросов (пускай что-то и не в каждом используется) и инициализируется, как правило, при старте сервера, в общем глобальный нэймспэйс. PHP при традиционном использовании (встраивание в сервер или fpm) фактически ведёт себя как CGI приложение, сбрасывая практически всё, единственно не порождая новый процесс интерпретатора на каждый запрос, между обработчиками передавать данные можно только через внешние сущности типа кукисов, сессий, IPC, файлов, APC, мемкэша или СУБД, причём передавать можно только сериализуемые данные. Если уж совсем утрировать, то хочется чтоб если есть во фронт-контроллере конструкция
Read-only данные, включая собственно исходный код приложения, вернее результат его интерпретации, обработанные конфиги и т. п., что постоянно для обработчиков всех запросов (пускай что-то и не в каждом используется) и инициализируется, как правило, при старте сервера, в общем глобальный нэймспэйс. PHP при традиционном использовании (встраивание в сервер или fpm) фактически ведёт себя как CGI приложение, сбрасывая практически всё, единственно не порождая новый процесс интерпретатора на каждый запрос, между обработчиками передавать данные можно только через внешние сущности типа кукисов, сессий, IPC, файлов, APC, мемкэша или СУБД, причём передавать можно только сериализуемые данные. Если уж совсем утрировать, то хочется чтоб если есть во фронт-контроллере конструкция
require_once 'superframework.php'; $app = new App(); $app->mainLoop(), то чтобы она отработала при старте сервера, а не при каждом запросе. Даже если хранить в каждом процессе копию всего этого барахла (я про байткод), то получится аж целых пара мегабайт на процесс. При современных объёмах оперативки на серверах это смешные цифры. Если поднапрячься — то можно в шаред мемори положить, тогда совсем оверхеда не будет. И то, что не получается 1 раз проинициализировать всё нужное, проблема PHP, а не обычного многопроцессного приложения. А точнее, это даже не проблема, а защита от дурака.
Я скорее не про память, а про процессор на интерпретацию этого байт-кода. Миллионы, а то и миллиарды раз в день его интерпретировать как-то жаба душит
Разве у nodы нет Jit копилятора? У пыха правда есть APC или eAccelerator, так что насчет интерпретации миллион раз на дню — это вы завернули :)
Не знаю. Я про PHP пишу, что без многопоточности на нём плохо, неэффективно расходуются ресурсы.
А APC и прочие кэшеры на интерпретацию никак не влияет, они кэшируют результаты компиляции исходников в байт-код, но не интерпретацию этого байт-кода.
А миллион раз в день приходится интерпретировать байт-код убогому чатику с 12 человеками онлайна, если чат обновляется раз в секунду.
А APC и прочие кэшеры на интерпретацию никак не влияет, они кэшируют результаты компиляции исходников в байт-код, но не интерпретацию этого байт-кода.
А миллион раз в день приходится интерпретировать байт-код убогому чатику с 12 человеками онлайна, если чат обновляется раз в секунду.
а переписать на лонг-пул? используя демонизацию? Там есть свои плюсы.
Долго думал над этим вот:
Компилятор читает (интерпретирует) source code и создает байт-код;
Байт-код не интерпретируется а исполняется.
Теперь про APC:
«APC обеспечивает ускоренное выполнение PHP-скриптов. Ускорение достигается путем компиляции PHP кода, который кэшируется и повторения компиляции можно почти полностью избежать.» Почти — потому, что есть такие бяки как «eval», которые исполняют (и компилят runtime) динамически генерируемый код (строку). Почитайте на досуге…
Я вам просто пару цифр оставлю: phpMyAdmin/Index (10.000 раз) без APC — 17.3s, c APC 2.35s.
Конечно APC не панацея — просто разговор шел про «Миллионы раз в день его интерпретировать как-то жаба душит...» — а это как раз чистый php-fpm без акселератора.
А APC и прочие кэшеры на интерпретацию никак не влияет, они кэшируют результаты компиляции исходников в байт-код, но не интерпретацию этого байт-кода.Вы спутали понятия интерпретация и компиляция, если упрощенно, то:
Компилятор читает (интерпретирует) source code и создает байт-код;
Байт-код не интерпретируется а исполняется.
Теперь про APC:
«APC обеспечивает ускоренное выполнение PHP-скриптов. Ускорение достигается путем компиляции PHP кода, который кэшируется и повторения компиляции можно почти полностью избежать.» Почти — потому, что есть такие бяки как «eval», которые исполняют (и компилят runtime) динамически генерируемый код (строку). Почитайте на досуге…
Я вам просто пару цифр оставлю: phpMyAdmin/Index (10.000 раз) без APC — 17.3s, c APC 2.35s.
Конечно APC не панацея — просто разговор шел про «Миллионы раз в день его интерпретировать как-то жаба душит...» — а это как раз чистый php-fpm без акселератора.
Байт-код исполняется путем его интерпретации. Чего-то вроду JIT в PHP нет. Ускорение достигается путем кэширования результатов компиляции. То есть без опкэшеров PHP на каждый вызов сначала компилирует исходники в байт-код в памяти, а потом его интерпретирует, а с ними компилирует только один раз, помещает результат в кэш, и при следующем вызрве сразу берёт байт-код.
А вы попробуйте написать теперь что-нибудь более серьезное, чем helloworld на 2МБ (я тоже про байт код). Что-то с крупными библеотеками, тысячами различных sql запросов (я про динамические конструкции, prepared statements, 35ГБ данных в месяц и т.д.), множественными связными деревьями в 100500 веток и т.д.
Я вам попытаюсь объяснить на примере нашего application server для одного такого приложения (кстати c++ и немного tcl + 2500 человеко дней работы).
single threaded (1 worker) front end жрет в пике 300MB, pipeliner (background) single threaded (1 worker) — 240MB.
Тоже самое с 3-я потоками 500MB и 312MB соответственно, с 10-ю всего 1350MB и 740MB соответственно.
Запустив 10 single threaded frontend и 10 single threaded pipeliner процессов я сожрал бы всю память на этой и двух соседних машинах. Ее можно конечно увеличить — только вот практика показывает, что максимальный performance increase получается при увеличении потоков, потом нодов на кластере и только в последнюю очередь — количества процессов на одной ноде.
Так-что не надо мне красиво расказывать кто-что делал и кто-что умеет и знает. В реальности иногда все обстоит совсем не так.
Это моя последняя попытка объяснить вам и возможно автору, что многопоточно и многопроцессорно есть две большие разницы — и только.
Я вам попытаюсь объяснить на примере нашего application server для одного такого приложения (кстати c++ и немного tcl + 2500 человеко дней работы).
single threaded (1 worker) front end жрет в пике 300MB, pipeliner (background) single threaded (1 worker) — 240MB.
Тоже самое с 3-я потоками 500MB и 312MB соответственно, с 10-ю всего 1350MB и 740MB соответственно.
Запустив 10 single threaded frontend и 10 single threaded pipeliner процессов я сожрал бы всю память на этой и двух соседних машинах. Ее можно конечно увеличить — только вот практика показывает, что максимальный performance increase получается при увеличении потоков, потом нодов на кластере и только в последнюю очередь — количества процессов на одной ноде.
Так-что не надо мне красиво расказывать кто-что делал и кто-что умеет и знает. В реальности иногда все обстоит совсем не так.
Это моя последняя попытка объяснить вам и возможно автору, что многопоточно и многопроцессорно есть две большие разницы — и только.
А вы работали когда нибудь активно с shared memory? Это же голая синхронизация без конца, причем далеко не тривиальная (concurrency, deadlock prevention, все дела ...). Почитайте хотя бы здесь на досуге.
все в шаредмемори положить не получится, плавали-знаем
В РНР существуют персистентные соединения, правда их не рекомендуется использовать
Это просто богоподная статья, которая просто идеально описала все на примере двух языков. Респект! Ресссспектттт!!!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Различия асинхронной и многопоточной архитектуры на примере Node.js и PHP