Не думаю что это рабочее решение. С таким же успехом можно мастерить асинхронный Python код который для доступа к базе дергает Go или JavaScript. Меня от этой идеи в дрожь бросает (и не потому что я Go/JavaScript недолюбливаю).
Django — не ко всем бочкам затычка. И эта затычка очень часто оказывается не той формы как дырка. Как ORM она ужасна.
Просто так вызывать блокирующий синхронный код нельзя — event loop залипает.
Запускать в thread pool — ненамного лучше. Под нагрузкой производительность начинает заметно проседать.
Остается два выхода:
Писать свои правильные асинхронные библиотеки
Поднять руку, резко её опустить и сказать: "И зачем мне эта асинхра? Буду до пенсии писать на Django!".
Первый вариант интересный и познавательный, второй — спокойный и стабильный.
Вероятно, у вас знакомство с asyncio исключительно теоретическое.
Чтобы переделать на корутины нужно менять сигнатуры кучи методов как минимум.
Получается новая библиотека, несовместимая со старой.
В том-то и дело.
1. Пишем блог
2. Добавляем комментарии (в топку disqus, мы же велосипедим!)
3. Добавляем runtime notifications для комментариев
На пункте 3 приплыли.
На самом деле не так много сайтов обходятся без такой системы.
Еще раз. Мне на сайте нужна система извещений пользователя о том что ему пришло какое-то сообщение.
WSGI не предполагает ничего подобного.
Если делать pull requests (не websockets и даже не long polling, это всё выходит за рамки WSGI) с приемлемой частотой (раз в секунду хотя бы) — быстро завалим любой сервер, как бы быстро запросы не отрабатывали.
Может у дядьки с одной из самых больших в мире соцсетей одни из самых мощных в мире серверов, откуда я знаю?
Попробуйте 400 worker-threads и классический сервер о 16 ядрах начнет спотыкаться. На 1600 — ляжет и заплачет. В то время как asyncio (tornado, twisted, nodejs) будет работать и не жужжать.
Но основной затык не в этом.
Так вышло, что синхронные сервера для питона все работают по стандарту WSGI. Который не поддерживает websockets и прочие варианты push-messages просто по определению. И это проблемма.
В asyncio запросы DNS делаются в thread pool если что.
И вообще если не думать — выстрелить себе в ногу можно абсолютно любым инструментом.
asyncio в этом отношении не проще и не сложнее.
У Майка своя колокольня — SQLAlchemy никогда не заработает с корутинами.
Но в целом согласен: «оно не надо, это только для веба».
Вопрос: вы, случайно, не разработкой для веба на хлеб зарабатываете?
Тогда ненужность асинхры — не звучит.
Не думаю что это рабочее решение. С таким же успехом можно мастерить асинхронный Python код который для доступа к базе дергает Go или JavaScript. Меня от этой идеи в дрожь бросает (и не потому что я Go/JavaScript недолюбливаю).
Просто так вызывать блокирующий синхронный код нельзя — event loop залипает.
Запускать в thread pool — ненамного лучше. Под нагрузкой производительность начинает заметно проседать.
Остается два выхода:
Первый вариант интересный и познавательный, второй — спокойный и стабильный.
sender_taskне нужен, шлите данные откуда естьВероятно, у вас знакомство с asyncio исключительно теоретическое.
Чтобы переделать на корутины нужно менять сигнатуры кучи методов как минимум.
Получается новая библиотека, несовместимая со старой.
чушь. Сказки для юных программистов.
Нельзя быть немного беременной, а потом надеяться как-то продумать ситуацию более детально.
Код или синхронный или — а\синхронный. Совмещать не удасться.
Это намек
Точнее, это можно делать пока у вас количество пользователей не больше десятка-двух.
Потом всё начнёт залипать.
Правильный PR здесь: github.com/mongodb/motor/pull/20
На самом деле самый правильный способ — это явное использование ClientSession
Из aiohttp то Flask пытаются сделать, то Django — и то и другое, думаю, зря. Разве что как эксперимент, чтобы поучиться писать.
Хотя сами попытки подтверждают, что библиотека получилась довольно удачная — можно крутить так и эдак.
1. Пишем блог
2. Добавляем комментарии (в топку disqus, мы же велосипедим!)
3. Добавляем runtime notifications для комментариев
На пункте 3 приплыли.
На самом деле не так много сайтов обходятся без такой системы.
WSGI не предполагает ничего подобного.
Если делать pull requests (не websockets и даже не long polling, это всё выходит за рамки WSGI) с приемлемой частотой (раз в секунду хотя бы) — быстро завалим любой сервер, как бы быстро запросы не отрабатывали.
Потому что для асихронных библиотек она катастрофически не подходит.
Попробуйте 400 worker-threads и классический сервер о 16 ядрах начнет спотыкаться. На 1600 — ляжет и заплачет. В то время как asyncio (tornado, twisted, nodejs) будет работать и не жужжать.
Но основной затык не в этом.
Так вышло, что синхронные сервера для питона все работают по стандарту WSGI. Который не поддерживает websockets и прочие варианты push-messages просто по определению. И это проблемма.
И вообще если не думать — выстрелить себе в ногу можно абсолютно любым инструментом.
asyncio в этом отношении не проще и не сложнее.
Но в целом согласен: «оно не надо, это только для веба».
Вопрос: вы, случайно, не разработкой для веба на хлеб зарабатываете?
Тогда ненужность асинхры — не звучит.
In [1]: import dis In [2]: def f(a, b): ...: a += b ...: In [3]: dis.dis(f) 2 0 LOAD_FAST 0 (a) 3 LOAD_FAST 1 (b) 6 INPLACE_ADD 7 STORE_FAST 0 (a) 10 LOAD_CONST 0 (None) 13 RETURN_VALUEНужная нам инструкция — это INPLACE_ADD. Один opcode, значит переключения GIL не происходит.