Здравствуйте, ·, Вы писали:

·>По обсуждаемой — по требованиям к CPU.

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

Z>>·>Ну и? Это какой-то сложный числодробительный процесс, который требует дохрена параллельно работающих CPU?
Z>>Откуда этот вывод?
·>Из контекста обсуждения.

И все же? Я утверждаю, что event loop не настолько хорош, чтобы заставлять программиста делать асинхронно абсолютно все IO. Вот и все. К чему эти вопросы с предполагаемым правильным ответом я не пойму. Сколько надо ядер, столько и задействуем, event loop может нам их сэкономить? Прекрасно, давай обсудим цифры, пока приводились 27%, что в целом, конечно не мало, но и не так уж круто. Хороший JIT JS экономит намного больше, а если переписать на C, легко сделаем экономию CPU на порядок, а то и 2. Только это все разбивается о тот факт, что намного важнее быстро выкатывать фичи, чем сэкономить несколько тысяч на CPU.

·>Ну "дешевле" — это осязаемая цель? А "насколько часто" — это вообще сложно оценить. В чём мерить частоту? Вот я и описываю сценарии когда оно так. А уж частота этих сценариев зависит от много чего и практически не поддаётся измерению.

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

·>Я видимо не понял о чём ты говоришь. Почему ты подразумеваешь, что "микросервис как источник данных" непременно должен быть REST? Почему ты подразумеваешь, что все REST сервисы непременно синхронные?

Микросервис как REST потому, что других стандартов либо нет или они еще хуже в контексте данного обсуждения. То, что REST непременно синхронный я не подразумеваю. Сервис может начать отдавать данные до того, как он получить от весь пакет БД, но ему все равно как минимум надо: а) синхронно получить запрос б) синхронно его обработать своей логикой и только потом начать делать что-то асинхронно. Ну и на практике такие кейсы это не правило, а какая-то точечная оптимизация, ибо большинство инструментов заточены на синхронную обработку: а) получили запрос, б) передали его в БЛ в) БД преобразовала в SQL г) отправила в БД д) бд выполнила и отдала результат е) БЛ как-то обработала результат и) преобразовала в json ж) сформировала респонс. Тут можно сказать БД, чтобы сразу отдавала JSON и перенаправлять вывод в респонс, но все равно остается куча неустранимых затыков из за которых прямой запрос к БД уже выполняется, а через HTTP все нет. Отсюда и увеличение латентности.

·>У тебя пресуппозиция. Почему не наоборот? Писать синхронный код только там, где это реально нужно.

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

·>Кстати, вспомни nodejs — это из мира веба. А веб это браузер. А в браузере только так и можно. Поэтому веб-программистам это понятно и близко.

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

·>Чужие эмоции я обсуждать не берусь.

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

·>Он не заменяет, естественно, а позволяет масштабировать. И внезапно упомянутые тобой выше таблицы авторизации — оказываются не нужны, и лазить в субд по каждому чиху в общем-то не нужно.

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

·>Если потоки не взаимодействуют, то это не синхронный код, т.к. синхронизировать-то нечего!

Мы по разному понимаем термин синхронный. Для меня синхронный код это код, у которого поток выполнения не разделяется на несколько. Даже если внутри он асинхронный, например в C# с кучей yield return. То есть вызов с await для меня синхронный, а без await — асинхронный, несмотря на то, что там никакие потоки не взаимодействуют, более того, там всего один поток.

Здравствуйте, ·, Вы писали:

·>Я думал что арифметика 1го класса — очевидная вещь... A < A + B, где A — "скейлить в процессы", B — "скейлить в потоки". Или ты считаешь, что "скейлить в потоки" — нулевая сложность?

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

·>При необходимости шаринг памяти делается не только между потоками.

А вот расшарить память между процессами в вебприложении уже намного сложнее. Ты встречал рабочие примеры?

·>В любом случае, ты переводишь тему с "скейлить проще" в "потребляют больше памяти/CPU".

Потому, что причина, по которой в ноде надо обвешивать код await это то, что без этого нода будет потреблять много памяти/CPU и просядет с отзывчивостью. Либо ей надо будет что-то менять в архитектура. Других причин нет, остальные платформы дают выбор — вызывать синхронный или асинхронный вариант и как-то справляются с быстродействием своими средствами (кто-то лучше кто-то хуже).

·>Чё? Нет, я считаю, что обработка ситуации исчерпания пула должна быть штатно.
·>Я видимо тогда тебя не понял... Кто что и зачем держит и кого надо счтитать тогда?

Каждый event в event loop, ждущий данные от БД, держит конекшен из пула. Этот конекшен нельзя вернуть в пул, пока не закроется транзакция. Поскольку количество запросов ушедших в ожидание данных у нас ничем не ограничено, то исчерпание пула это лишь вопрос нагрузки сервиса и БД. При разбиении на процессы/потоки, балансировщик просто не сможет отдать запрос в приложение и засунет в буфер или дождется когда кто-то освободится. При event loop тоже можно сделать такое поведение, если ситуация "кончился пул" штатная и приложение просто складывает этот евент в очередь до освобождения конекншена и берет следующий.

Вот этот момент мне тоже интересен и буду рад, если кто-то достоверно расскажет, что предлагает нода на этот случай.

Здравствуйте, Ziaw, Вы писали:

Z>·>Я думал что арифметика 1го класса — очевидная вещь... A < A + B, где A — "скейлить в процессы", B — "скейлить в потоки". Или ты считаешь, что "скейлить в потоки" — нулевая сложность?

Z>Близкая к нулю. Сложность заключается в том, чтобы не использовать глобальные переменные.

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

Здравствуйте, Ziaw, Вы писали:

Z>·>Если потоки не взаимодействуют, то это не синхронный код, т.к. синхронизировать-то нечего!

Z>Мы по разному понимаем термин синхронный. Для меня синхронный код это код, у которого поток выполнения не разделяется на несколько. Даже если внутри он асинхронный, например в C# с кучей yield return. То есть вызов с await для меня синхронный, а без await — асинхронный, несмотря на то, что там никакие потоки не взаимодействуют, более того, там всего один поток.

Это у тебя какая то собственная терминология. Асинхронный, значит время выполнения разных частей разное. await всего лишь организует логическое связывание конктекста и результата. Буквально он ничего не сихронизирует и это легко проверить — запускаешь параллельно N "синхронных" цепочек и ловишь race condition.
При чем нет никакой разницы, что под капотом, события или потоки — все равно будет race condition.

Здравствуйте, Ikemefula, Вы писали:

I>Это у тебя какая то собственная терминология. Асинхронный, значит время выполнения разных частей разное.

Моя терминология близка к википедии.

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

Если рассматривать алгоритмический граф как основной поток программы (а какие-то другие основные потоки мы вряд ли сможем выделить), то они совпадают.

А вот твоя какая-то непонятная, откуда ты ее взял?

I>При чем нет никакой разницы, что под капотом, события или потоки — все равно будет race condition.

И чо?

Здравствуйте, Ikemefula, Вы писали:

I>Потоковая модель хорошо ложится на архитектуру железа, но она же и сложнее ровно по этой же причине.

Чем хорошо-то? Железо эффективнее используется как раз в эвентлупе, не надо переключать потоки, просто обрабатываем следующий евент.

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

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

Здравствуйте, Ziaw, Вы писали:

Z>Мы по разному понимаем термин синхронный. Для меня синхронный код это код, у которого поток выполнения не разделяется на несколько. Даже если внутри он асинхронный, например в C# с кучей yield return. То есть вызов с await для меня синхронный, а без await — асинхронный, несмотря на то, что там никакие потоки не взаимодействуют, более того, там всего один поток.

По моему ты съехал с темы. Речь не про синхронность внешнюю, а про блокирующий и неблокирующий IO. И даже при наличии yield или await неблокирующий IO блокирующим не становится.

Здравствуйте, Ziaw, Вы писали:

Z>Моя терминология близка к википедии.
Z>

Z>Асинхронные действия — действия, выполненные в неблокирующем режиме, что позволяет основному потоку программы продолжить обработку[6].

Где здесь определение "синхронный" ? Где здесь "await делает код синхронным?" Кроме того, здесь про потоки, сам смотри. Т.е. это определение не годится для JS.

I>>При чем нет никакой разницы, что под капотом, события или потоки — все равно будет race condition.

Z>И чо?

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

Здравствуйте, Ziaw, Вы писали:

I>>Потоковая модель хорошо ложится на архитектуру железа, но она же и сложнее ровно по этой же причине.

Z>Чем хорошо-то? Железо эффективнее используется как раз в эвентлупе, не надо переключать потоки, просто обрабатываем следующий евент.

Это зависит от задачи. Если потоки не конкурируют за ресурсы, то у тебя количество вычислителей = количество ядер. А в событийной модели типа нода будет 1 вычислитель.

Модель нода хорошо работает только если вычислений нет вовсе. В противном случае количество вычислений == степень блокирования эвентлупа вплоть до отказа в обслуживании.

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

Z>У меня складывается ощущение, что ты сказал что-то умное, но я никак не могу понять что. Что ты называешь событийной моделью и какие высокоуровневые абстракции она предлагает?

Да всё то же. Мы сравниваем потоки и event loop. event loop — событийныая модель.

Здравствуйте, Lexey, Вы писали:

L>·>Ведь довольно очевидно, имхо, что скейлить только в процессы проще, чем скейлить и в процессы, и в потоки.
L>На самом деле не только не очевидно, но и в общем случае неверно.
L>Пример из реальной жизни: есть K шардов, из которых можно читать сообщения пачками по M штук. Один шард можно читать только одним клиентом. Проще всего будет как раз схема, в которой читают K процессов, а внутри них пачки сообщений разгребаются на пуле потоков. На процессах это тоже можно сделать, но результат получается сильно более сложным в реализации.
И как это противоречит моему тезису?
В твоём случае решение с K процессами, которые будут разгребать однопоточно M сообщений — будет очевидно проще. И только в том случае, если не хватает производительности (вы ведь делали перфтесты, да?) — его придётся усложнить заскейлив на потоки.

Да и вообще говоря, я про общий случай не говорил. Я говорил о типичном веб-сервере. Мы ведь nodejs подход ещё обсуждаем или что?

Здравствуйте, Ziaw, Вы писали:

Z>·>По обсуждаемой — по требованиям к CPU.
Z>А откуда они вообще взялись? Мне кажется, что ты пытаешься приписать мне какую-то точку зрения, но не могу понять на какую.
Многопоточность необходима если у тебя есть несколько конкурентных потоков исполнения, т.е. работают несколько CPU одновременно. Если у тебя потоки это просто способ переключать стеки — один поток поработал, разбудил другой поток, передал ему управление, заснул в ожидании результата — то это по сути использование потоков не по назначению — и кроме накладных расходов и излишней сложности никаких преимуществ не даёт. В nodejs пошли другим путём — зачем потоки, когда можно сделать события с тем же результатом.

Z>>>Откуда этот вывод?
Z>·>Из контекста обсуждения.
Z>И все же? Я утверждаю, что event loop не настолько хорош, чтобы заставлять программиста делать асинхронно абсолютно все IO. Вот и все. К чему эти вопросы с предполагаемым правильным ответом я не пойму. Сколько надо ядер, столько и задействуем, event loop может нам их сэкономить? Прекрасно, давай обсудим цифры, пока приводились 27%, что в целом, конечно не мало, но и не так уж круто. Хороший JIT JS экономит намного больше, а если переписать на C, легко сделаем экономию CPU на порядок, а то и 2. Только это все разбивается о тот факт, что намного важнее быстро выкатывать фичи, чем сэкономить несколько тысяч на CPU.
Асинхронное IO — решение более простое и дешевое в условиях типичных веб-серверов. Если ты вводишь понятие потоков и соответственно всяких примитивов синхронизации — это такой огромный can of worms — volatile, mutex, ABA, deadlock, happens-before, ... и ещё штук сто страшных слов... И это по сути всё заменяется на один единственный await.

Z>·>Ну "дешевле" — это осязаемая цель? А "насколько часто" — это вообще сложно оценить. В чём мерить частоту? Вот я и описываю сценарии когда оно так. А уж частота этих сценариев зависит от много чего и практически не поддаётся измерению.
Z>Если ты забыл, все это длинное дерево началось с моего вопроса к разработчикам ноды, насколько это часто. Мне интересен реальный опыт, различные гипотетические сценарии я и сам прекрасно умею представлять.
Судя по полуярности ноды — охрененно часто.

Z>·>Я видимо не понял о чём ты говоришь. Почему ты подразумеваешь, что "микросервис как источник данных" непременно должен быть REST? Почему ты подразумеваешь, что все REST сервисы непременно синхронные?
Z>Микросервис как REST потому, что других стандартов либо нет или они еще хуже в контексте данного обсуждения.
По поему опыту "обычно" микросервисы вешаются на какую-нибудь шину, типа kafka, без всякого rest.

Z>То, что REST непременно синхронный я не подразумеваю. Сервис может начать отдавать данные до того, как он получить от весь пакет БД, но ему все равно как минимум надо: а) синхронно получить запрос б) синхронно его обработать своей логикой и только потом начать делать что-то асинхронно. Ну и на практике такие кейсы это не правило, а какая-то точечная оптимизация, ибо большинство инструментов заточены на синхронную обработку: а) получили запрос, б) передали его в БЛ в) БД преобразовала в SQL г) отправила в БД д) бд выполнила и отдала результат е) БЛ как-то обработала результат и) преобразовала в json ж) сформировала респонс. Тут можно сказать БД, чтобы сразу отдавала JSON и перенаправлять вывод в респонс, но все равно остается куча неустранимых затыков из за которых прямой запрос к БД уже выполняется, а через HTTP все нет. Отсюда и увеличение латентности.
Не понял к чему ты ведёшь — да, добавили больше хопов, увеличилась латентность. И? Причём тут треды? Зачем непременно ждать-то ответа на мутексе, вместо асинхрона?

Z>·>У тебя пресуппозиция. Почему не наоборот? Писать синхронный код только там, где это реально нужно.
Z>Потому, что если логика синхронная, то и писать лучше синхронно. А не устилать код синхронизирующими костылями для быстродействия платформы, как это делается сейчас.
Что такое "синхронная логика"? Треды-евенты — это детали реализации логики, а не логика.

Z>·>Кстати, вспомни nodejs — это из мира веба. А веб это браузер. А в браузере только так и можно. Поэтому веб-программистам это понятно и близко.
Z>При этом сделана куча фреймворков в которых в которых ее маскируют по максимуму, чтобы асинхронность не торчала ушами совсем уж ото всюду.
Эээ. А именно?

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

Z>·>Он не заменяет, естественно, а позволяет масштабировать. И внезапно упомянутые тобой выше таблицы авторизации — оказываются не нужны, и лазить в субд по каждому чиху в общем-то не нужно.
Z>По каждому может и не нужно, но кеширование это всего лишь кеширование, а уметь вычислять некешированную авторизацию все равно нужно. Особенно если в ней есть правила вроде — пользователь не оставить комментарий, если прошло более трех дней с момента публикации.
А её обязательно вычислять в отдельном потоке? Или можно просто пожертвовать десятком миллисекунд раз в час?

Z>·>Если потоки не взаимодействуют, то это не синхронный код, т.к. синхронизировать-то нечего!
Z>Мы по разному понимаем термин синхронный. Для меня синхронный код это код, у которого поток выполнения не разделяется на несколько. Даже если внутри он асинхронный, например в C# с кучей yield return. То есть вызов с await для меня синхронный, а без await — асинхронный, несмотря на то, что там никакие потоки не взаимодействуют, более того, там всего один поток.
"не синхронный" != "асинхронный". Просто понятие не применимо.

Здравствуйте, Ziaw, Вы писали:

Z>·>Я думал что арифметика 1го класса — очевидная вещь... A < A + B, где A — "скейлить в процессы", B — "скейлить в потоки". Или ты считаешь, что "скейлить в потоки" — нулевая сложность?
Z>Близкая к нулю.
И по этому по многопоточности пишут дохрена книг, защищают докторские и потом всё равно спотыкаются на каком-нибудь reordering.

Z>Сложность заключается в том, чтобы не использовать глобальные переменные.
Причём тут глобальные переменные?! Сложность возникает когда нужно хоть какое-то взаимодействие между потоками или когда больше одного потока взаимодействует с одним ресурсом.

Z>·>При необходимости шаринг памяти делается не только между потоками.
Z>А вот расшарить память между процессами в вебприложении уже намного сложнее. Ты встречал рабочие примеры?
Ну в вебе это будет какой-нибудь redis/kafka.

Z>·>В любом случае, ты переводишь тему с "скейлить проще" в "потребляют больше памяти/CPU".
Z>Потому, что причина, по которой в ноде надо обвешивать код await это то, что без этого нода будет потреблять много памяти/CPU и просядет с отзывчивостью. Либо ей надо будет что-то менять в архитектура. Других причин нет, остальные платформы дают выбор — вызывать синхронный или асинхронный вариант и как-то справляются с быстродействием своими средствами (кто-то лучше кто-то хуже).
Вообще-то если await не повесить — она летать начнёт, ибо ждать ничего не будет. Правда код будет слишком ВНЕЗАПНО работать.
Если ты предлагаешь вместо await добавить в js многопоточность — ну нафиг. Проще пристрелить.

Z>·>Чё? Нет, я считаю, что обработка ситуации исчерпания пула должна быть штатно.
Z>·>Я видимо тогда тебя не понял... Кто что и зачем держит и кого надо счтитать тогда?
Z>Каждый event в event loop, ждущий данные от БД, держит конекшен из пула. Этот конекшен нельзя вернуть в пул, пока не закроется транзакция. Поскольку количество запросов ушедших в ожидание данных у нас ничем не ограничено, то исчерпание пула это лишь вопрос нагрузки сервиса и БД. При разбиении на процессы/потоки, балансировщик просто не сможет отдать запрос в приложение и засунет в буфер или дождется когда кто-то освободится. При event loop тоже можно сделать такое поведение, если ситуация "кончился пул" штатная и приложение просто складывает этот евент в очередь до освобождения конекншена и берет следующий.
Не понял в чём отличие многопоточного решения — каждый поток берёт из пула соединение и держит пока не закроется транзакция.
Количество запросов ушедших в ожидание можно банально считать.
Код получается проще — никаких CAS, atomic, etc не нужно, простой инкремент.

Z>Вот этот момент мне тоже интересен и буду рад, если кто-то достоверно расскажет, что предлагает нода на этот случай.
Про ноду я ничего не знаю.

Здравствуйте, Ziaw, Вы писали:

I>>Потоковая модель хорошо ложится на архитектуру железа, но она же и сложнее ровно по этой же причине.
Z>Чем хорошо-то? Железо эффективнее используется как раз в эвентлупе, не надо переключать потоки, просто обрабатываем следующий евент.
В общем случае неверно. Железо эффективнее с потоками если "обрабатываем следующий евент" занимает значительное вычислительное время. И, вместо того, чтобы у тебя обработка шла на одном CPU, можно нагрузить много ядер сразу.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>По моему ты съехал с темы. Речь не про синхронность внешнюю, а про блокирующий и неблокирующий IO. И даже при наличии yield или await неблокирующий IO блокирующим не становится.

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

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

Z>Я не спорю, что неблокирующий IO может тратить меньше ресурсов. Могу лишь сомневаться в том, что это играет большое значение, поскольку серверные мощности для самого приложения относительно дешево масштабируются, а реальный выигрыш надо тестить, синтетика показывает небольшое увеличение. Для этой темы у нас с тобой есть отдельная ветка. В этой же тема другая, я пытаюсь договориться с Ikemefula о общих понятиях. Пока получается слабо, диалог не складывается.

есть чемпионаты Highload Cup
где народ пытается реализовать все возможными доступными языками программирования
разные подходы

помниться по последним результатам победил С, epoll
https://highloadcup.ru/ru/rating/
реализации сами можете поискать, но треиды по моему в пролете

Здравствуйте, ·, Вы писали:

·>И по этому по многопоточности пишут дохрена книг, защищают докторские и потом всё равно спотыкаются на каком-нибудь reordering.

Только это все никак не относится к масштабированию вебприложений.

·>Причём тут глобальные переменные?! Сложность возникает когда нужно хоть какое-то взаимодействие между потоками или когда больше одного потока взаимодействует с одним ресурсом.

А зачем это взаимодействие при скейлинге? Там задача максимально снизить взаимодействие между потоками.

·>Ну в вебе это будет какой-нибудь redis/kafka.

Как он снизит требования к памяти у одного процесса приложения?

·>Вообще-то если await не повесить — она летать начнёт, ибо ждать ничего не будет. Правда код будет слишком ВНЕЗАПНО работать.
·>Если ты предлагаешь вместо await добавить в js многопоточность — ну нафиг. Проще пристрелить.

Я предлагаю проектировать системы так, чтобы программист не был обязан постоянно писать await. Этож 99.9% вызовов IO в типичном сферическом приложении. Если не решать задачу в лоб, я уверен, что можно было сделать и рабочий event loop и возможность таких вызовов. Прямо сейчас решение не могу сказать, но видится что-то реактивное, прерываемое на ожидании IO этакими yield'ами. Вывернуть наизнанку этот loop, короче.

Моя претензия к node и фреймворкам на нем именно в постоянном пренебрежении к программисту, все проектируется так, как проще пишущему фреймворк, а программисты привыкнут. Есть в этом что-то общее с PHP и его фреймворками. Вроде простые вещи можно сделать достаточно просто, но как только представляешь себе масштабный проект — хочется потушить свет и мысль резко начинает работать в сторону микросервисов и прочей декомпозиции. Сложность растет слишком быстро и непонятно как ей управлять, нет стандартных практик, все в каких-то километровых конфигах, начиная с пачки импортов в каждом файле, которой можно наконфигурять так, что читающий код просто офигеет. Надо писать какие-то объемные код стайлы и прочие документашки, в которых прописано, как все работает и что от чего зависит, потому, что по коду прочитать это практически нереально. Куча программистов плохо понимает как работает система модулей (хотя бы одна) и относятся к ней как какой-то магии. Причем это не только бэкенд, к фронту все относится не в меньшей степени. Разве что во фронте проще разделить проект на не связанные части и поддерживать каждую отдельно и при каких-то проблемах просто выкинуть компонент и переписать его нафиг, благо они относительно дешевые.

Здравствуйте, Ziaw, Вы писали:

Z>поскольку серверные мощности для самого приложения относительно дешево масштабируются

Вот как раз блокирующий IO масштабируется плохо.

Здравствуйте, ·, Вы писали:

·>это такой огромный can of worms — volatile, mutex, ABA, deadlock, happens-before, ... и ещё штук сто страшных слов...

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

·> И это по сути всё заменяется на один единственный await.

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

Здравствуйте, ·, Вы писали:

·>В общем случае неверно. Железо эффективнее с потоками если "обрабатываем следующий евент" занимает значительное вычислительное время. И, вместо того, чтобы у тебя обработка шла на одном CPU, можно нагрузить много ядер сразу.

Слушай, а у тебя есть опыт в вебразработке? У меня ощущение, что ты мыслишь принципами десктопщика. Вот правда, видишь проблемы там где их нет и не видишь там, где они есть.

Масштабировать веб приложение на много ядер сразу очень просто, как процессами, так и тредами, потому, что оно stateless. Никакой проблемы с многопоточностью в понимании десктопного программиста нет. Различие между event loop и обычной моделью в том, что event loop не требуется переключать поток. Когда один евент отработал часть запроса и ушел в ожидание IO, поток тут же берет следующий event из очереди. Можно запустить потоки по количеству ядер и не париться. В приложениях без EL потоки конкурируют за CPU, засыпая на ожидании IO. Чтобы полностью загрузить CPU потоков нужно больше чем ядер, но с какого-то количества идет оверхед на конкуренцию и переключение между потоками с возможным вытеснением данных из кеша процессора. Это может казаться серьезным ударом по производительности, но редко является проблемой для бизнеса, поскольку масштабируется относительно дешево, что физическими серваками, что облаками.

Тот же гитхаб очень отзывчиво работает на относительно тормозном руби, а битбакет тупит на относительно быстром python. Facebook умудряется быть шустрым на PHP, а LinkedIn тормозит на nodejs.

Все зависит от людей, которые делают сервис.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>·>это такой огромный can of worms — volatile, mutex, ABA, deadlock, happens-before, ... и ещё штук сто страшных слов...
НС>Неблокирующее IO от этого не избавляет — колбеки в нормальных платформах зовутся в отдельном потоке все равно.
Да, но это в ядре системы, написанном высококвалифицированными программистами и вылизанном десятки лет, а не в бизнес-логике, которая меняется каждый день вчерашними студентами.

НС>Неблокирующее IO не для избавления от потоков, а для того чтобы не держать потоки, если мы можем подождать прерывание.
Мы тут сравниваем два подхода
— "классическиий" — пул воркер-потоков обработки запросов, которые блокируются на IO с субд, например.
— nodejs — один поток, который обрабатывает запросы и передаёт их в асинхронное IO.
Т.е. по факту "избавление от потоков".

НС>·> И это по сути всё заменяется на один единственный await.
НС>Нет, не заменяется. Это заменяется кооперативной многозадачностью либо принудительной синхронизацией колбеков, которые к await никакого отношения не имеют
С т.з. языка программирования.