я не обсуждаю nodeJS, я говорю про странные требования к соискателям - в веб-разработке СОП не используется
-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Вакансия: ищу профессионалов в команду нового стартапа (поиск товаров и услуг)
- Автор темы Rin
- Дата начала
Rin
*
Krishna
>Мало что лучше масштабируется, нежели чистый PHP, который, если говорить о приложении без учёта работы с СУБД масштабируется строго линейно. Надо в 2 раза больше запросов обработать - удвой количество серверов.
:-D
Вы не поверите, но JSv8 ещё быстрее, чем PHP. Докупать железо необязательно.
>если говорить о приложении без учёта работы с СУБД
При больших нагрузках СУБД всё равно будет на другом сервере.
Raziel[SD]
>Это на основании теории или практики использования node.js? (масштабирование)
NodeJS -- это всего лишь инструмент, вместо него м.б. другая платформа, реализующая СОП и асинхронность.
Важно увеличить не только производительность, но и время отклика.
Важно увеличить не только производительность, но и уменьшить время отклика. (пропустил слово)
Асинхронную генерацию блоков можно вынести на отдельные сервера, чтобы улучшить производительность и время отклика.
В синхронной генерации блоков увеличится производительность, но время откликаувеличится уменьшится (описался) несущественно, т.к. ждать ответа всё равно придётся последовательно.
Даже теоретических знаний достаточно, чтобы понять это.
Главная страница Яндекса, например, собирается асинхронно.
Вот ещё вам.
Benchmarking Node.js - basic performance tests against Apache + PHP
>Мало что лучше масштабируется, нежели чистый PHP, который, если говорить о приложении без учёта работы с СУБД масштабируется строго линейно. Надо в 2 раза больше запросов обработать - удвой количество серверов.
:-D
Вы не поверите, но JSv8 ещё быстрее, чем PHP. Докупать железо необязательно.
>если говорить о приложении без учёта работы с СУБД
При больших нагрузках СУБД всё равно будет на другом сервере.
Raziel[SD]
>Это на основании теории или практики использования node.js? (масштабирование)
NodeJS -- это всего лишь инструмент, вместо него м.б. другая платформа, реализующая СОП и асинхронность.
Важно увеличить не только производительность, но и уменьшить время отклика. (пропустил слово)
Асинхронную генерацию блоков можно вынести на отдельные сервера, чтобы улучшить производительность и время отклика.
В синхронной генерации блоков увеличится производительность, но время отклика
Даже теоретических знаний достаточно, чтобы понять это.
Главная страница Яндекса, например, собирается асинхронно.
Вот ещё вам.
Benchmarking Node.js - basic performance tests against Apache + PHP
Я бы к преимуществам асинхронной блочной сборки отнес еще устойчивость — сохранение работоспособности остальных блоков при проблемах на каком-то из ни достигается легко в противовес последовательному построению, что особенно важно в случае наличия множества различных малосвязанных сервисов
Rin
*
grigori
>в веб-разработке СОП не используется
В браузере очень давно используется.
И на сервере: Python / Twisted
Вы, кажется, проспали ;-)
Добавлено позже:
http://nodejs.org/jsconf.pdf
>в веб-разработке СОП не используется
В браузере очень давно используется.
И на сервере: Python / Twisted
Вы, кажется, проспали ;-)
Добавлено позже:
http://nodejs.org/jsconf.pdf
Krishna
Продался Java
Rin
1. Вы действительно не понимаете разницы между производительностью и масштабируемостью.
А тесты, которые приводятся как доказательство веб-разработчиков могут только насмешить. Очень показательно, что они абсолютно нереалистичные, это с высокой вероятностью позволяет утверждать, что на реальных приложениях картина скорее всего прямо противоположная.
Более того, могу Вас заверить, что компилируемая в оптимизированный машинный код Java на подобных недо-тестах по производительности разорвёт с громким треском и фигурным узором как JS, так и PHP. Однако, по каким-то причинам она всё более сдаёт позиции в классических веб-проектах, отступая в энтерпрайз и мобильный сектор.
Но, повторюсь, я говорил о масштабируемости. Просто мантры про асинхронность звучат очень странно и к повышению масштабируемости не приводят ни во мне известной теории, ни, разумеется, насколько я понял, на практике.
2. Вы путаете асинхронность сборки страницы на клиенте и асинхронность приложения на сервере. Поблочную сборку страницы ответами с разных серверов можно реализовать на PHP точно так же, как и на Вашем NodeJS. Может у NodeJS будут какие-то особые плюшки для этого дела, но зато у него с высокой вероятностью не будет 90% из того, что предложит PHP. Именно по той причине, что он (NodeJS) является нераспространённым решением, навряд ли рассчитанным на создание крупных веб-приложений. По этой же причине Вы не найдёте разработчиков потратив сопоставимые усилия с поиском умельцев работающих в конкурентно-способных технологиях.
Резюмируя, я бы Вам советовал поискать сначала опытного веб-разработчика, готового взять на себя обязанности технического руководителя проекта и выбор технологий возложить на него. Ежели в данном проекте эта должность уже Ваша, то я бы посоветовал поднабраться опыта и знаний, прежде чем заниматься проектами такого уровня.
1. Вы действительно не понимаете разницы между производительностью и масштабируемостью.
А тесты, которые приводятся как доказательство веб-разработчиков могут только насмешить. Очень показательно, что они абсолютно нереалистичные, это с высокой вероятностью позволяет утверждать, что на реальных приложениях картина скорее всего прямо противоположная.
Более того, могу Вас заверить, что компилируемая в оптимизированный машинный код Java на подобных недо-тестах по производительности разорвёт с громким треском и фигурным узором как JS, так и PHP. Однако, по каким-то причинам она всё более сдаёт позиции в классических веб-проектах, отступая в энтерпрайз и мобильный сектор.
Но, повторюсь, я говорил о масштабируемости. Просто мантры про асинхронность звучат очень странно и к повышению масштабируемости не приводят ни во мне известной теории, ни, разумеется, насколько я понял, на практике.
2. Вы путаете асинхронность сборки страницы на клиенте и асинхронность приложения на сервере. Поблочную сборку страницы ответами с разных серверов можно реализовать на PHP точно так же, как и на Вашем NodeJS. Может у NodeJS будут какие-то особые плюшки для этого дела, но зато у него с высокой вероятностью не будет 90% из того, что предложит PHP. Именно по той причине, что он (NodeJS) является нераспространённым решением, навряд ли рассчитанным на создание крупных веб-приложений. По этой же причине Вы не найдёте разработчиков потратив сопоставимые усилия с поиском умельцев работающих в конкурентно-способных технологиях.
Наверное я Вас удивлю, но при нагрузках порядка Я.Маркета сервер СУБД будет не "другой", а таких серверов будет десяток-другой. С непростой схемой репликации, шаринга или вообще кластером.
Резюмируя, я бы Вам советовал поискать сначала опытного веб-разработчика, готового взять на себя обязанности технического руководителя проекта и выбор технологий возложить на него. Ежели в данном проекте эта должность уже Ваша, то я бы посоветовал поднабраться опыта и знаний, прежде чем заниматься проектами такого уровня.
MiksIr
miksir@home:~$
Да лана, для финансового успеха проекта пофиг, на какой коленке он сделан. А в дальнейшем его всегда можно подложить костылями и переделать =)
И все-равно все свалится к банальному PHP ибо челу просто не найти вменяемого разработчика, который знает все, что он запланировал, да еще да за такие деньги.
И все-равно все свалится к банальному PHP ибо челу просто не найти вменяемого разработчика, который знает все, что он запланировал, да еще да за такие деньги.
Я умею «увеличивать время отклика»!
Вам во сколько раз?
Rin
*
Важно увеличить не только производительность, но и уменьшить время отклика (было пропущено важное слово).
Та статья на Хабре про производительность -- враньё или это был NodeJS v0.1.
Я просто оставлю это
http://habrahabr.ru/blogs/nodejs/129640/#comment_4328588
и это
http://habrahabr.ru/blogs/nodejs/129640/#comment_4295937
и вот ещё
http://habrahabr.ru/blogs/nodejs/129640/#comment_4293503
Та статья на Хабре про производительность -- враньё или это был NodeJS v0.1.
Я просто оставлю это
http://habrahabr.ru/blogs/nodejs/129640/#comment_4328588
и это
http://habrahabr.ru/blogs/nodejs/129640/#comment_4295937
и вот ещё
http://habrahabr.ru/blogs/nodejs/129640/#comment_4293503
MiksIr
miksir@home:~$
Странные тесты там. Ясно дело, что неблокируещее касается ввода-вывода. Так что такие асинхронные решения - отличное средство для быстрой промежуточной обработки данных... а веб по сути этим и занимается. Ну и ясно дело, рабочих процессов должно быть несколько. Так что чего там автор хотел доказать, я так и не понял.
MiksIr
miksir@home:~$
А так, если подумать, что мы экономим на асинхронном решении? Не именно об этом node.js, а любом.
Ну, вероятно, память. Раньше у нас было несколько десятков воркеров PHP, которые только и делали, что спали в отжидании ответа базы, по-этому то их и несколько десятков без проблем. Сейчас у нас несколько воркеров асинхронных, которые не спят вообще, по-этому сильно больше, чем число ядер в системе, их не запустишь. Однако, данные каждого запроса тоже нужно хранить где-то, так что экономия памяти есть, но меньше, чем можно было бы ожидать.
Каково в данном случае процессору я не знаю - не настолько хорошо знаю шедулер. Но интуитивно чувствую, что разницы особой нет.
Какие еще плюсы?
Поехали минусы. Ну, помнить о числах фибоначи, да. Т.е. сложная математика не катит. Поведение менее стабильное в целом - какие-то баги и краши застопорят или прибъют нафиг не один запрос, а сразу приличную пачку - т.е. все, что висят на этом воркере. Диск, кстати, приносит так же много неприятностей в плане асинхронности - те, кто раздают много всего с диска nginx-ом, думаю, знают, зачем приходится ставить кучу воркеров.
Ну, вероятно, память. Раньше у нас было несколько десятков воркеров PHP, которые только и делали, что спали в отжидании ответа базы, по-этому то их и несколько десятков без проблем. Сейчас у нас несколько воркеров асинхронных, которые не спят вообще, по-этому сильно больше, чем число ядер в системе, их не запустишь. Однако, данные каждого запроса тоже нужно хранить где-то, так что экономия памяти есть, но меньше, чем можно было бы ожидать.
Каково в данном случае процессору я не знаю - не настолько хорошо знаю шедулер. Но интуитивно чувствую, что разницы особой нет.
Какие еще плюсы?
Поехали минусы. Ну, помнить о числах фибоначи, да. Т.е. сложная математика не катит. Поведение менее стабильное в целом - какие-то баги и краши застопорят или прибъют нафиг не один запрос, а сразу приличную пачку - т.е. все, что висят на этом воркере. Диск, кстати, приносит так же много неприятностей в плане асинхронности - те, кто раздают много всего с диска nginx-ом, думаю, знают, зачем приходится ставить кучу воркеров.
MiksIr
Автор - известный знатный тролль и завсегдатай 4chan-а, чего ты хочешь. =)
Серьезно (если понимаешь, чем отличается cpu bound приложение от i/o bound) это обсуждать не стоит. А поглумиться над "node.js is web scale" - самое то
Касаемо процессора - context switch же.
Автор - известный знатный тролль и завсегдатай 4chan-а, чего ты хочешь. =)
Серьезно (если понимаешь, чем отличается cpu bound приложение от i/o bound) это обсуждать не стоит. А поглумиться над "node.js is web scale" - самое то
Касаемо процессора - context switch же.
MiksIr
miksir@home:~$
Да, про контекст свитч то я понимаю, просто не очень представляю, насколько он будет оказывать влияние, так как и в случае PHP - большинство процессов спит в ожидании io от базы.
Зато еще что подумалось... если запросы будут разные по математике... немного тяжелых и много легких, то из-за малого количества воркеров время отклика на легкие запросы может плавать, так как тяжелые захватят все воркеры. Это можно еще в минусы асинхронности записать.
Зато еще что подумалось... если запросы будут разные по математике... немного тяжелых и много легких, то из-за малого количества воркеров время отклика на легкие запросы может плавать, так как тяжелые захватят все воркеры. Это можно еще в минусы асинхронности записать.
Печалька. почему вы так агресивно настроены против инородного языка. Nodejs очень здорово подходит для простых штук, которые держат огромное количество подключений. Очень здорово подходит для простых динамических вещей: чаты, проверка обновлений страницы, ленты новостей, счётчики, реалтайм статистика, лайки и т.д. Оптимальная связка Nodejs + MongoDb. Как только сложность увеличивается и нужно собирать страницу, работать с мускулом и т.д., то здесь лучше использовать более классический ООП подход, потому что иерархия замкнутых функций вызывает ужос при их виде.
Асинхронность, масштабированность - это маркетинговый ход. Как правило хватает одного сервера, про "честное горизонтальное масштабирование" никто авторитетный из использующих ноде не рассказывал.
Асинхронность, масштабированность - это маркетинговый ход. Как правило хватает одного сервера, про "честное горизонтальное масштабирование" никто авторитетный из использующих ноде не рассказывал.
Rin
*
Krishna
>Наверное я Вас удивлю, но при нагрузках порядка Я.Маркета сервер СУБД будет не "другой", а таких серверов будет десяток-другой. С непростой схемой репликации, шаринга или вообще кластером.
Не удивили, наверняка там кластер.
>Вы путаете асинхронность сборки страницы на клиенте и асинхронность приложения на сервере.
Это где я путаю? Мне про клиента вообще говорить не интересно.
>Вы действительно не понимаете разницы между производительностью и масштабируемостью.
Масштабируемость -- это способность выдерживать увеличившиеся нагрузки.
Масштабируемость достигается только путём увеличения производительности (софт и/или железо).
Вертикальное масштабирование у NodeJS лучше, у php, т.к. он быстрее (производительнее), а Тед это "тролль".
Загрузка блоков страницы с других серверов -- это горизонтальное масштабирование. И глупо делать это не асинхронно.
>Поблочную сборку страницы ответами с разных серверов можно реализовать на PHP точно так же, как и на Вашем NodeJS
можно, но не так же, как в СОП NodeJS.
В PHP нужно крутить в бесконечном цикле socket_select() или curl_multi_exec() и ждать когда все соединения "пропукаются", вместо того, что бы ловить события для каждого соединения отдельно.
>Наверное я Вас удивлю, но при нагрузках порядка Я.Маркета сервер СУБД будет не "другой", а таких серверов будет десяток-другой. С непростой схемой репликации, шаринга или вообще кластером.
Не удивили, наверняка там кластер.
>Вы путаете асинхронность сборки страницы на клиенте и асинхронность приложения на сервере.
Это где я путаю? Мне про клиента вообще говорить не интересно.
>Вы действительно не понимаете разницы между производительностью и масштабируемостью.
Масштабируемость -- это способность выдерживать увеличившиеся нагрузки.
Масштабируемость достигается только путём увеличения производительности (софт и/или железо).
Вертикальное масштабирование у NodeJS лучше, у php, т.к. он быстрее (производительнее), а Тед это "тролль".
Загрузка блоков страницы с других серверов -- это горизонтальное масштабирование. И глупо делать это не асинхронно.
>Поблочную сборку страницы ответами с разных серверов можно реализовать на PHP точно так же, как и на Вашем NodeJS
можно, но не так же, как в СОП NodeJS.
В PHP нужно крутить в бесконечном цикле socket_select() или curl_multi_exec() и ждать когда все соединения "пропукаются", вместо того, что бы ловить события для каждого соединения отдельно.
Ну, тут не верно — пхп вполне умеет libevent