Здравствуйте, Ziaw, Вы писали:
Z>Причина — можно рассовать 1000 IO по потокам и тогда у нас вроде как 1000 запросов могут обрабатываться одновременно.
Зачем это делать?
НС>>Проблема не в переключении контекстов, а в том что такая схема плохо реагирует на резкий рост нагрузки. Z>Резкий рост нагрузки все равно упрется в БД.
Он и в БД упрется, и деградацию на серверах с веб-приложением устроит. Сами по себе тормоза в БД не так страшны пока у тебя IO неблокирующее. А вот когда блокирующее — у тебя система не просто тормозить начинает, а становится раком.
Здравствуйте, Ziaw, Вы писали:
Z>В любом случае, память лишней не бывает.
Бывает. Вариантов куча. Помимо историй со стандартными линейками в облаках бывают и более экзотические ситуации. К примеру, память нам нужна для быстрого стартапа, потому что от скорости стартарпа зависит скорость скейлинга. А вот после старта такие объемы могут быть и не нужны.
Здравствуйте, Sharov, Вы писали:
S>1000 запросов одновременно это ни о чем сегодня. Остальная сотня тысяч или более будет стоять в очереди с соотв. user experience.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Зачем это делать?
Зачем мне задавать такие вопросы? Ты же эксперт по ASP.NET, расскажи если есть что.
НС>Он и в БД упрется, и деградацию на серверах с веб-приложением устроит. Сами по себе тормоза в БД не так страшны пока у тебя IO неблокирующее. А вот когда блокирующее — у тебя система не просто тормозить начинает, а становится раком.
Объясни разницу, почему встает? Допустим и там и там у нас 1000 потоков держат конекшен к БД и ждут пока она выдаст данные. Без как только появляется ответ — поток вебсервера просыпается и отдает ответ клиенту.
Я еще могу понять коллегу, который утверждает, что модель с одним потоком обработает все гораздо эффективнее за счет отсутствия необходимости у ядра переключать контексты. А вот твою точку зрения не очень понимаю, за счет чего выигрыш отдельного пула из 1000 IO потоков, которые ждут асинхронно?
Здравствуйте, mogadanez, Вы писали:
Z>>Ну в принципе где-то уровень PHP уже есть, если закрыть глаза на бесящую принудительную асинхронность, ненужную в подавляющем большинстве случаев.
M>async/await ?
Да-да-да. Недавно хотел JSON-RPC, так штук 10 библиотек просмотрел, все на коллбеках. Благо протокол простенький, сам написал необходимое.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ziaw, Вы писали:
НС>>Зачем это делать? Z>Зачем мне задавать такие вопросы? Ты же эксперт по ASP.NET, расскажи если есть что.
Я, как эксперт, советую не рассовывать ничего по 1000 потоков. А вот ты почему то этого упорно хочешь.
Z>Объясни разницу, почему встает?
Я тебе ссылку уже давал.
Z>Я еще могу понять коллегу, который утверждает, что модель с одним потоком обработает все гораздо эффективнее за счет отсутствия необходимости у ядра переключать контексты. А вот твою точку зрения не очень понимаю, за счет чего выигрыш отдельного пула из 1000 IO потоков, которые ждут асинхронно?
Ты что то там себе нафантазировал. IO потоки в пуле не ждут асинхронно, эти потоки нужны для отработки колбеков из ядра.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Я, как эксперт, советую не рассовывать ничего по 1000 потоков. А вот ты почему то этого упорно хочешь.
Ты написал, про 1000 потоков на ядро в ASP.NET, а хочу рассовать по ним я, причем упорно. Отличный прием.
НС>Ты что то там себе нафантазировал. IO потоки в пуле не ждут асинхронно, эти потоки нужны для отработки колбеков из ядра.
И что дальше они делают после отработки колбэка? В каком потоке продолжается выполнение обработчика запроса и как это организовано? Я никак не пойму за счет чего выигрыш, вот тут кто-то делает предположения, что эти потоки чем-то легче обычных потоков в винде, это так? В чем принципиальное отличие твоих 1000 IOCP потоков от 1000 обычных потоков?
Здравствуйте, ·, Вы писали:
·>А подробнее? Какой процент IO занимает? Если заявленные тобой 70%, то что же там CPU вычисляет сотни миллисекунд? Биткойны что-ли майнит?
Не суть важно. Мидлварь, шаблонизатор, ORM, GC на любой динамике способны сожрать вагон CPU. И до определенного момента дешевле покупать CPU, чем оптимизировать эти затраты.
·>Кстати, надо считать не конкретно IO, а сколько времени треды проводят и в waiting, и в blocked.
Доли процента.
·>Растёт, ибо железо улучшается.
Последние годы оптимизируется именно IO. Если взять разницу между топовой конфой 10-летней давности и текущей, выигрыш на IO будет на порядки больше выигрыша от CPU. Время проведенное на IO уменьшается быстрее, чем на загрузке CPU (а фреймворки становятся все тормознее). Посмотри по своей ссылке, там все и правда очень наглядно.
·>Ну или студент на nodejs. Ибо сама бизнес-логика обычно примитивна — три с половиной ифа.
Там другие сложности при разработке. Не вложить максимум в такт процессора, а сделать понятный и поддерживаемый код. Не превратить проект в груду неподдерживаемых макарон к которым страшно подойти.
Многие сдались и ушли в микросервисы. Все становится в разы дороже, глючнее и тормознее, зато риск того, что весь проект станет макаронами стремится к нулю. Переписать с нуля десяток-другой микросервисов бизнес готов, а заморозить фичи на несколько лет в ожидании нового продукта — нет.
Здравствуйте, alex_public, Вы писали:
_>Да, возможно. Это я утверждаю, что он не нужен. Во всех задачах, кроме тех, где требуются тысячи одновременных потоков исполнения.
_>Ну если говорить про Node.js, то его однопоточность является вовсе не следствием приверженности асинхронного ввода-вывода, а скорее следствием принципиальной однопоточностью JS-движка V8 — там как бы изначально особо выбора не было. Хотя в итоге библиотечка libuv (второй основной компонент node.js, помимо v8, как раз отвечающий за асинхронный вывод-вывод) получилась очень не плохая и используется во многих других проектах.
Все верно. Вместо избавления от мешающего принципа сделали отличный и удобный костыль. Я как раз про это и веду речь, а меня все время переключают на дискуссии по производительности.
_>Вообще говоря оно не быстрее в абсолютных цифрах. Пока число одновременных запросов меньше количества ядер процессора, оно будет даже медленнее. Главный нюанс тут не в абсолютных значения, а в функции зависимости производительности от количества одновременных запросов. У классической многопоточности эта функция намного печальнее, чем у асинхронного подхода. И соответственно чем большее число одновременных запросов у нас будет, тем существеннее будет разница в быстродействие. И это общеизвестных факт, во всяком случае для всех, кто хоть немного в теме веб'а и т.п.
Так я вроде с ним и не спорю. Мой поинт в том, что наш RPM так или иначе упирается в БД и оптимизировать надо там. От того, что мы можем держать в приложении одновременно большее количество ждущих запросов пропускная способность не вырастет.Как верно говорит НС, это нам даст возможность пережить пик без отказа в обслуживании, но эта задача решается разными способами.
Еще вариант — вебсокеты, вот там действительно можно получить вагон одновременных соединений, но эти вещи как раз в любом фреймворке организованы как event loop и там это действительно имеет смысл.
_>Удобство конечно же лучше у синхронного кода. Хотя использование сопрограмм (aync/await и т.п., если они доступны в языке) приводит внешний вид асинхронного кода к подобию синхронного (хотя внутри там на самом деле происходят довольно сложные процессы, но про них необязательно знать начинающим).
Не такие уж и сложные на необходимом прикладному программисту уровне абстракции. Понимать что такое промисы и как работает event loop все равно нужно.
Здравствуйте, Ziaw, Вы писали:
Z>·>А подробнее? Какой процент IO занимает? Если заявленные тобой 70%, то что же там CPU вычисляет сотни миллисекунд? Биткойны что-ли майнит? Z>Не суть важно. Мидлварь, шаблонизатор, ORM, GC на любой динамике способны сожрать вагон CPU. И до определенного момента дешевле покупать CPU, чем оптимизировать эти затраты.
Это так в ентерпрайзе с полутора пользователями. А там работает всё. Хоть один тред, хоть тыща — всё одинаково тормозит и никак не скейлится.
Z>·>Растёт, ибо железо улучшается. Z>Последние годы оптимизируется именно IO. Если взять разницу между топовой конфой 10-летней давности и текущей, выигрыш на IO будет на порядки больше выигрыша от CPU. Время проведенное на IO уменьшается быстрее, чем на загрузке CPU (а фреймворки становятся все тормознее). Посмотри по своей ссылке, там все и правда очень наглядно.
Насчёт тормознутости фреймворков я что-то сомневаюсь. Какой-нибудь Websphere таки потяжелей и тормозней той же ноды.
Z>·>Ну или студент на nodejs. Ибо сама бизнес-логика обычно примитивна — три с половиной ифа. Z>Там другие сложности при разработке. Не вложить максимум в такт процессора, а сделать понятный и поддерживаемый код. Не превратить проект в груду неподдерживаемых макарон к которым страшно подойти.
Эээ.. И помогает?
Z>Многие сдались и ушли в микросервисы. Все становится в разы дороже, глючнее и тормознее, зато риск того, что весь проект станет макаронами стремится к нулю. Переписать с нуля десяток-другой микросервисов бизнес готов, а заморозить фичи на несколько лет в ожидании нового продукта — нет.
Просто проще интегрировать стало, собираешь из кусочков. Раньше у тебя был какой-нибудь IBM DistributedMap и дай бог там всё что нам надо и работает как мы хочем, а сейчас ты можешь сам выбирать — redis/hazelcast/memcached и ещё всякое, да ещё и менять на ходу.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Это так в ентерпрайзе с полутора пользователями. А там работает всё. Хоть один тред, хоть тыща — всё одинаково тормозит и никак не скейлится.
Что ты подразумеваешь под словом ентерпрайз, скейлится и тормозит? Вот gmail это энетрпрайз или нет? Он скейлится, торомозит или все вместе?
·>Насчёт тормознутости фреймворков я что-то сомневаюсь. Какой-нибудь Websphere таки потяжелей и тормозней той же ноды.
нода это интерпретатор js. Ее нельзя сравнивать с websphere.
·>Эээ.. И помогает?
Помогает.
·>Просто проще интегрировать стало, собираешь из кусочков. Раньше у тебя был какой-нибудь IBM DistributedMap и дай бог там всё что нам надо и работает как мы хочем, а сейчас ты можешь сам выбирать — redis/hazelcast/memcached и ещё всякое, да ещё и менять на ходу.
Не, микросервисы это про другое. Это когда мы все приложение разбиваем на условно независимые сервисы, связывая их контрактами API. Один отвечает за пользователей, второй за их профайлы, третий за маршруты, четвертый за билеты. И считаем, что можем один сервис писать на Go, а вместо второго использовать ActiveDirectory.
Здравствуйте, alex_public, Вы писали:
_>Более того, с этой точки зрения нет абсолютно никакой разницы между IOCP кодом и кодом с созданным пользователем потоком, в котором используется блокирующая операция ввода-вывода.
Благодарю, крайне познавательно. Но тут не согласен, когда речь идет о нагруженном приложении пропускная способность c IOPC будет больше, ибо бы будем ему делегировать io операции,
не блокировав тем самым пользовательский поток, который сможет начать обрабатывать другой запрос. В однопоточном случае разница будет небольшой, тут согласен.
Здравствуйте, Ziaw, Вы писали:
S>>А для одного ядра 1000 запросов енто много?
Z>Смотря каких запросов, на каком фреймворке и за какой промежуток времени.
Пускай .net, 1000 rps. Много или как? Я честно не знаю, енто больше дискуссионный вопрос.
Здравствуйте, Sharov, Вы писали:
S>Пускай .net, 1000 rps. Много или как? Я честно не знаю, енто больше дискуссионный вопрос.
Если это реальное приложение (какой-нибудь orchard cms, если он еще жив), а не тестовый обезжиренный контроллер, то на одно ядро много. Я не мерял, пальцевнебный прогноз — 100.
Здравствуйте, Ziaw, Вы писали:
Z>Если это реальное приложение (какой-нибудь orchard cms, если он еще жив), а не тестовый обезжиренный контроллер, то на одно ядро много. Я не мерял, пальцевнебный прогноз — 100.
