Стоит ли использовать асинхронный драйвер для postgres?

Pavel Denisov, А, всегда - в рамках моей задачи и асинхронной логики. Я вас не правильно понял вначале. Спасибо

Стоит ли использовать асинхронный драйвер для postgres?

Roman Kitaev, мне, кстати, команда pip3 search psycopg2 выдала в результатах некую psycopg2-binary, Может это оно и есть?

Стоит ли использовать асинхронный драйвер для postgres?

Pavel Denisov, Всегда? Даже если бекенд синхронно отправляет запросы к ней в одном процессе? А какие в этом случае примущества?

Стоит ли использовать асинхронный драйвер для postgres?

Roman Kitaev, спасибо за разъяснение. Тогда оставлю всё как есть сейчас

Стоит ли использовать асинхронный драйвер для postgres?

Кроме того можно ведь обращаться к синхронной базе на psycopg2 через run_in_executor()

Стоит ли использовать асинхронный драйвер для postgres?

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

Но это толкьо предположение

Какие проблемы могут возникнуть с aiohttp?

Скажу, что это всегда хорошая практика, даже в однозадачном коде.

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

Какие проблемы могут возникнуть с aiohttp?

Херню пишут.

А в чём тогда отличия? кроме async await и запуска eventloop'ов, разумеется. В чём будет состоять разница в логике реализации? Я уже пописал немного и прочёл официальное руководство - действительно возникло впечатление, будто структура кода похожа на то, как это выглядит, например, во flask.

Какие проблемы могут возникнуть с aiohttp?

Теперь понятно, почему присваивание проходит верно.

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

А что скажете по поводу

Для повышения производительности лучше писать коррутины маленькими и разбивать задачи на кучу подпрограмм? или напротив, лучше всё запихивать в одну коррутину?

?

Помогитре разработать алгоритм или какую взять библиотеку для визуализации графа?

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

Решает ли Django Channels проблему с блокирующими запросами?

Сергей Горностаев, А можно ведь, думаю, распределить нагрузку и всё.
Для не особенно долгих запросов использовать django channels, а для долгих отправлять запросы на aiohttp с http frontend сервера

Решает ли Django Channels проблему с блокирующими запросами?

Сергей Горностаев, Огромное Вам спасибо! Прямо разложили всё по полочкам!

Решает ли Django Channels проблему с блокирующими запросами?

Сергей Горностаев, Но если в секунду нужно обрабатывать скажем 1000 соединений и каждое обрабатывается 1 секунду, то нужно 1000 воркеров :)
Они конечно не автоматически плодятся, а запускаются разработчиком

Решает ли Django Channels проблему с блокирующими запросами?

Сергей Горностаев, То есть я хоте сказать Django + Celery может больше?

Django Channels - это почти как Django + Celery. Основная разница только в возможности удерживать множество открытых соединений.

Решает ли Django Channels проблему с блокирующими запросами?

Сергей Горностаев, Понял. Значит процессы всё таки плодятся - мне показалось что процессов больше не становится, поэтому не мог понять, как так получается. Спасибо.
Но тогда выходит что если соединений очень много, то channels будет кушать немало памяти ввиду того что придётся запустить много воркеров чтобы быстро обрабатывать всех клиентов и требования к железу возрастают?

Решает ли Django Channels проблему с блокирующими запросами?

И я так понимаю, Celery может удерживать больше соединений?

Решает ли Django Channels проблему с блокирующими запросами?

Например во вьюхе прописан запрос к базе. 10 клиентов через daphne отправляют запросы 5 воркерам. воркеры далее отправляют эти запросы на вьюху. Сперва первые 5 штук. Получается в этом случае вьюха отправит 5 запросов к базе одновременно? и будет ждать секунду когда вернутся ответы, затем обратно отдаст ответы воркерам и примет следующие 5 запросов? так? Даже несмотря на то что во вьюхе код блокирующий?

Решает ли Django Channels проблему с блокирующими запросами?

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

То есть меня интересуют не детали реализации, а схема работы
П.С. В Celery я так же не до конца понял Consumer'ы :)

Какой фреймворк выбрать в качестве альтернативы django?

marazmiki, я про flask )
Но уже разобрался впринципе, спасибо

Какой фреймворк выбрать в качестве альтернативы django?

Сергей Горностаев, понял, спасибо