Область применения асинхронного программирования?

Да то что в каждом конкретном случае производительность может упасть так как обработчик может быть "занят" пока не дойдет до него очередь, но в целом если смотреть то по идее производительность должна увеличиться.

А как насчет не долгих блокировок, чтение/запись в бд в основном происходят за 50-100 мл секунд, но даже вроде в этом случае это должно дать положительный эффект нет?

То что асинхронный подход несколько сложнее и легко свалить всю систему одним долгим синхронным вызовом это я знаю, но какие задачи должно решать приложение что бы это случилось как я понял это какие сложные длительные вычисления которые будут грузить сам процессор но это ведь не 99% сайтов web'a.

Мне просто хочется понять где и какой выигрыш может дать применение асинхронного подхода, и когда я читал статьи то мне на секунду показалось что выигрыш должен быть даже при типичным web сайте(обычные запросы к бд, рендеринг отображения), вопрос только стоит ли игра свеч?

wpbloger: > А как насчет не долгих блокировок, чтение/запись в бд в основном происходят за 50-100 мл секунд, но даже вроде в этом случае это должно дать положительный эффект нет?

В общем случае нет:
1) если смотреть на конкретный запрос, то оба и синхронный и асинхронный вариант завершаться за одинаковое время (50-100 мс), т.е. зависит от БД.
2) Если смотреть под нагрузкой, много параллельных запросов, то асинхронный код будет проигрывать, если кол-во поток достаточно в много-поточной версии.

Например если рассмотреть конкретный запрос в БД на 50мс, если БД сможет потянуть в 10 потоков этот запрос, то она выдаст 200 rps и съест весь проц. в итоге на остатки ресурсов процессора веб сервер выдаст результат, итого будет не более 200 rps.

Если это не БД, а легкий запрос, или БД находится не на текущем хосте, тогда можно прикинуть так:
нужно выжать 5к rps, задержка 50мс, значит один поток 1000/50 = 20 rps, для 5k нужно 250 потоков.
Итого при 250 потоках, многопоточное приложение выиграет у асинхронного, т.к. асинхронному нужно тратить часть ресурсов на обслуживание самой асинхронщины и переключение задач, когда в многопоточном это делает ОС и проц максимально быстро.
Кстати (в питоне) 250 потоков могут съесть всего 7-20Мб памяти (зависит от приложения).

Гляньте этот тред: https://habrahabr.ru/post/282972/#comment_8881620
Расход на асинхронщину составил 80-90%, итого async.io выдал 1000 rps, а блокирующее на uwsgi 7000 rps

Ещё сам авторы tornado-web (асинхронный фреймворк) использовали блокирующий вызов в БД, утверждая что особо профита от асинхоронного нет.

lega: да похоже много шумихи насчет асинхронной модели выполнения, и больно нет смысла обычные сайты пилить под ней, но как я понял если нужно держать много одновременных соединений то тут определенно нужно использовать асинхронную модель выполнения ведь много потоков тоже создать не получится, я прав?

wpbloger: Да, для долгих конектов (веб-сокеты/закачка) это стоит того.

> больно нет смысла обычные сайты пилить под ней

у разработчиков под node.js и выхода нет, хотя они оправдываются promise, async/await, но все равно это не то.

Плохо то что достаточно грамотные разработчики попадаются (под этот маркетинг), хотя асинхронщина интересна, и это может затянуть в "болото".