@maxkain если проникнешься и поймешь то, что говорим, тогда поймешь почему в разговоре про бенчмарки я спрашивал профиль нагруз. потому что асинхронщина уже, грубо говоря, на всех языках работает с одинаково высокой скоростью, а вот если бы профиль нагрузки был “числодробительный”, cpu bound, тогда выигрышь от go, rust’а и прочих подобных языков был бы больше заметен, если найдешь такой бенчмарк, можно сравнить

Но это не отменяет того что на 1 задачу на сайте ты бегаешь в базу по 5 раз

Представь классический пример с вордпрессом

Там запросы к базе десятками из-за плагинов

Не сильно они затратны. Ну может быть какая то экономия небольшая.

1 поток при асинхронном подходе может выполнить гораздо больше работы на io нагрузке, гораздо, потому что в то время как при классическом подходе потоку нужно ожидать, асинхронный поток работает, причем, как тебе сказали выше, время ожидания io настолько больше времени выполнения каких-то действий на проце, что асинхронный подход дает значительный буст

Да и базовое подтянуть - имя юзера, права юзера, запропшрапемве данные, какие-нить мета, каталог для меню... И не важно откуда из sql или кэша это все равно io

Ну да, то есть создать 500 потоков (а то и форков в случае с PHP) и переключаться между ними дешевле, чем сложить 500 запросов к БД в общую очередь и расчищать её в одном потоке?
Вы пробовали когда-нибудь профилировать код?

Такие задачи делаются демонами запуском множества процессов... Без всякой асинхронщины

Без переиництации кода... Тысячи задач на пид по очереди

Не очень эффективно зато на том же яп с тем же ООП, сервисами, модулями

Допустим у тебя одинаковое количество синхронных и асинхронных воркеров, асинхронные смогут выполнить больше работы (обработать больше запросов) потому что пока у синхронных воркеров простой в ожидании io, асинхронные воркеры работают. Тут логика очень простая. А учитывая то, что простои очень большие по сравнению с временем работы на ЦПУ, то и работы асинхронные воркеры делают ГОРАЗДО больше, то есть буст прям очень и очень существенный.

Я про то, что ускорение в бенчмарках тех не за счет экономии на io, а за счет режима запуска. Посмотри разницу между symfony и symfony-swoole. А там разница в веб сервере, код одинаковый.

В на практике быстрее и надежнее там где балки, брокеры очередей контролирующие в тч краши апп и прочие индексы бд.

А на nodejs у программистов почему-то другим голова занята

Если тебе на ноджс будет приходить много задач io, они тоже могу стать в очередь

Те да при прочих равных можно добиться несущестаенного ускорения. Иногда разы но редко на порядки

Да и те простои компенсируются кол-вом процессов пусть и в ущерб времени на переключение процессов. Зато в сухом остатке экономится на времени программиста

И на пхп вынужденно больше внимания уделяется не экономии на ио

Я привел тебе аргументы. Конкретно “на пальцах” объяснил как работает и засчет чего выигрыш Ты с аргументами согласен?

Ну так и ноджс можно поднять не 1 инстанс а миллион