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

Question

[wpbloger]

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

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

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

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

Answer 1

[lega]

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

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

Асинхронный подход имеет смысл (только) когда в задаче есть долгие блокировки (веб-сокеты, сетевые закачки с зависаниями) - когда поток весит и ждет события, тогда вместо 10к потоков, можно все задачу уложить в один асинхронный поток.

Все бы нечего, но проблема в том что сложность асинхронного кода гораздо выше в разных аспектах, итого времени может тратится в разы больше (год на проект вместо 4 мес например).

Поэтому асинхронность применять лучше там где это оправдано (для веб-сокетов), а весь остальной проект делать "классически". А сейчас из-за моды некоторые пытаются целиком все асинхронным кодом делать, потом иногда по прошествии года/двух появляются статьи о том что асинхронность не стоит того, а их в комментариях обливают, что мол не умеете готовить.

Более разумным видится использование файберов/корутин, но эту тему не сильно развивают.

Comments

[wpbloger]

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

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

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

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

[lega]

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 (асинхронный фреймворк) использовали блокирующий вызов в БД, утверждая что особо профита от асинхоронного нет.

[wpbloger]

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

[lega]

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

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

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

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

Answer 2

[Александр Пожарский]

Грубо говоря - профит в ситуациях, в которых процесс простаивает во время выполнения операции (например, указанные в вопросе ситуации).

Соответственно, если работа происходит синхронно - в это время невозможна работа с другими запросами. Если юзаются "системные" потоки - уже лучше, но накладные расходы относительно высоки. Ну и существуют подходы, позволяющие лучше утилизировать 1 поток (нодовое event-driven, golang-е горутины и прочее).

Answer 3

[Rou1997]

На серверной стороне если протокол HTTP и сервер Apache/nginx, то асинхронность и многозадачность используется абсолютно всегда, на клиентской это AJAX и т.п., AJAX оптимизирует и клиентскую и серверную сторону, если только сервер не будет опрашиваться слишком часто.