Совмещение асинхронного и синхронного программирования — это плохо?

Question

[Max Payne]

И так, я недавно задавал вопрос про выбор асинхронной ORM для MongoDB на Python 3.7, так и не нашёл ни одной, которая устраивала бы меня по количеству доступных полей, основные которые рассматривал - motorengine, umongo, aiomotorengine и ещё штук пять.
Сегодня в очередном порыве гугления случайно наткнулся на статью Motor vs PyMongo - Asynchronous vs Synchronous DB calls, в которой у автора асинхронный motor (на котором, собственно, построены почти все асинхронные ORM) был всегда медленнее синхронного pymongo.
В комментариях некий араб объяснил это тем, что мотор создаёт лишь иллюзию асинхронности.

Цитата

There is a simple reason why Motor is slower than pymongo. Because it is NOT truly asynchronous. Let me tell you why.

For any IO application to be called asynchronous, at the heart of it, it needs to be using NON BLOCKING SOCKETS (basic OS concepts every CS Major is aware of). Motor does not. It simply throws up a new thread (tell me about the genius in that??) every time you make a call. It is super resource intensive as a result. Each thread is simply running a pymongo instance, which finally at the end of the day, is using the same old blocking IO socket :) :D (He he he, fooled you!!!)

Once the thread retrieves the result from the socket, it returns to the caller in an non-blocking fashion, wonderfully throwing up the illusion of a so called 'asynchronicity'

Собственно вопрос: если у меня весь код, кроме вызовов БД, будет работать на том же синхронном mongoengine, а всё остальное асинхронно - будет ли профит, или эти блокировки нивелируют прирост производительности?

Answer 1

[longclaps]

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

Answer 2

[Roman K]

Сейчас много что в питоне создаёт иллюзию асинхронности пулом тредов. Ничего в этом удивительного нет. Если асинхронный код выполнять как синхронный (что и происходит в статье) — он будет медленней синхронного. Очевидно же, что синхронный выполняется последовательно, а асинхронным нужно управлять — постоянные свичи "контекста", сколько-то времени тратит event loop на себя, треды порождаются долго (если "асинхронность" на тредах).

Производительность не в том, что запросы должны лететь быстрее, а в том, что другой код может выполняться, пока запрос к БД висит. Потому что он висит в отдельном треде и никому не мешает (за исключением всяких edge-кейсов, которые блокируют все треды). Да, часто пула тредов может не хватать (по умолчанию это 5 * количество_ядер). Например, если ты пытаешься через aiohttp скачать 100к страниц. Но в этом случае синхронный был бы раз в 40 медленней (на 8-ядерном процессоре). И этот пул при желании можно увеличить. Но я сильно сомневаюсь, что затык будет в тредах, а не в сети.