Комментарии 12
Мсье знает толк…
Как по мне — давно пора уже открыть для себя asyncio и выкинуть python 2 на свалку истории.
Как по мне — давно пора уже открыть для себя asyncio и выкинуть python 2 на свалку истории.
Не всегда asyncio подходит. Не всегда подходит python 3. Плюс ко всему asyncio позволяет работать только с сетевым IO и с модулем subprocess. Как насчет файлового IO? Как быть с библиотеками, которые реализуют множество интерфейсов и протоколов, все переписывать на asyncio? Asyncio — это светлое будущее, но в суровом настоящем это, в основном, боль, в условиях, когда приходится работать над бизнес-проектами.
нет конечно, сидеть и ждать, когда python 3 обрастет на 87% поддержкой библиотек — наверное, тоже своеобразная стратетия, но, граждане программисты, вы программисты или где?
Не хватает какой-то либы? Сядь и напиши, будь мужиком! Андрей Светлов сидит и пилит пачку библиотек под asyncio и мы уже полгода как сидим на его aiohttp, aiopg, aioredis и нормально себя чувствуем. О какой боли вы говорите — для меня загадка. =)
Не хватает какой-то либы? Сядь и напиши, будь мужиком! Андрей Светлов сидит и пилит пачку библиотек под asyncio и мы уже полгода как сидим на его aiohttp, aiopg, aioredis и нормально себя чувствуем. О какой боли вы говорите — для меня загадка. =)
И тут врывается такой начальник с криками: «Почему так долго? Сроки горят, клиенты уходят, конкуренты уже 100500 фич запилили, а вы тут чем занимаетесь, дармоеды?»
aioredis
А профит есть? У меня в тестах блокирующий redis работал даже быстрее, чем его неблокирующий анагалог.
Это всё от того, что блокирующий код быстрее асинхронного. Что, вроде как, должно быть самоочевидным фактом.
Это очевидно. Если говорить точнее, то создание genTask/Future может быть затратнее и дольше чем блокировка потока. Собственно, поэтому я и задал этот вопрос. В чём смысл использовать aioredis?
Мое мнение по этому вопросу. Проблемы с потоками начинаются когда их становится слишком много, или когда забивается очередь пулла, а нам жизненно необходимо быстро обратиться к ресурсу. Тут и получается выигрыш от асинхронности, так как на поддержание и создание соединения не нужно выделять ресурсы на создание потока или же ожидать высвобождения потока из очереди. А так как синхронный код работает только в потоке, то общая производительность системы падает, падает rps. Если соединений не много, то потоки будут выгоднее асинхронности зачастую (особенно если используется пулл), но при возрастании нагрузки отдельно работающий быстрее код будет заторможен внешними зависимостями — переключением контекста, блокировками и другими особенностями многопоточных приложений.
А при чем тут потоки? :)
Когда я проводил тесты (с tornado, правда), то у меня обращения с использованием асинхронной библиотеки redis были более затратными по ресурсам и времени, чем использование блокирующей. Всё дело в том, что redis весьма шустрый, и получается, что блокировка потока на время ожидания ответа от redis оказывается выигрышнее, чем создание genTask/Future и выполнение асинхронного запроса. Плюс ко всему, получается, что в принципе (если других блокирующих запросов нет) заблокированный поток после разблокировки может сразу отдать данные, и идти обрабатывать запросы, не возвращаясь более к этому.
Или Вы используете aioredis для подключения к каналам?
Когда я проводил тесты (с tornado, правда), то у меня обращения с использованием асинхронной библиотеки redis были более затратными по ресурсам и времени, чем использование блокирующей. Всё дело в том, что redis весьма шустрый, и получается, что блокировка потока на время ожидания ответа от redis оказывается выигрышнее, чем создание genTask/Future и выполнение асинхронного запроса. Плюс ко всему, получается, что в принципе (если других блокирующих запросов нет) заблокированный поток после разблокировки может сразу отдать данные, и идти обрабатывать запросы, не возвращаясь более к этому.
Или Вы используете aioredis для подключения к каналам?
Я не использую aioredis, я использую deferToGreenlet где у меня вызывается простой блокирующий код библиотеки redis (внутри которой select, os, socket, threading… ), вызовы которого перехватываются gevent. Так что не знаю, в чем разница именно aioredis (как асинхронной реализации redis) и redis. Gevent довольно реактивен (внутри libevent), в своих тестах разницы производительности не замечаю. В любом случае есть опасность заблокировать процесс при использовании целиком синхронного редиса в асинхронном приложении (без greenlets а именно на coroutine), при условии если redis вдруг затормозит, затупит, зависнет или случится какая-то беда внутри сети.
Использование блокирующего IO в асинхронном коде с кооперативной многозадачностью — это факап по-определению.
А ещё есть inlineCallbacks. Метод тоже из разряда «серединка на половинку».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Синхронный код в асинхронном Twisted, или сказ о том, как скрестить ежа с ужом