DNS в asyncio синхронный.
Для DNS-запросов создается (автоматически) thread pool. При большом количестве запросов к разным хостам это здорово тормозит работу (по умолчанию их 5), а если увеличивать размер пула — производительность падает уже из-за большого количества переключений контекста. Да и смысл асинхронности теряется.
Вопрос был именно в контексте uvloop.
С самим asyncio я достаточно давно знаком. Правда, в части клиентских приложений (в т.ч. в связке с aiohttp).
Правильно ли я понимаю, что:
1. Описанный в оригинальной статье httptools в клиентских приложениях поможет не сильно.
2. Вопрос с синхронным dns-резолвером в asyncio/aiohttp все еще открытый (я знаю про aiodns, но подружить их лично у меня не получилось).
По описанию штука действительно крутая. Но интересует больше real world тестов. В жизни, все-таки, мы пишем что-то более сложное чем просто echo-сервер.
Даёт ли профит в связке с motor/другими асинхронными драйверами БД?
.lib спасает только от блокировки по URL/домену.
В случае перехода на https-only, как я уже писал выше, блокировать будут по IP. Ну есть еще вариант — MITM-proxy на стороне провайдера, чем он плох, думаю, писать не надо.
>Пока что шифрование доступно в виде опции при авторизации, а скоро будет включено по умолчанию для всех пользователей.
Эх, похоже, что скоро нельзя будет пользоваться альтернативными доменами — блочить будут сразу по IP, как это делают со всеми остальными HTTPS-only ресурсами.
Возможно я не до конца понимаю матчасть, но разве «не анонсируется» тождественно равно «не используется»? Ведь может компания использовать «белые» адреса для каких-то своих внутренних целей, для которых не подходят «серые» адреса, и не анонсировать их наружу?
Многопроцессность в текущих тестовых сборках достаточно условная — т.н. «single content process model». Т.е. рендерит все страницы один процесс. При краше все равно умирают все вкладки, но хоть интерфейс остается живой.
multiple content process будет только после релиза первого варианта, т.е. еще очень как не скоро: https://wiki.mozilla.org/Electrolysis/Multiple_content_processes и там блокеров намного больше.
DNS в asyncio синхронный.
Для DNS-запросов создается (автоматически) thread pool. При большом количестве запросов к разным хостам это здорово тормозит работу (по умолчанию их 5), а если увеличивать размер пула — производительность падает уже из-за большого количества переключений контекста. Да и смысл асинхронности теряется.
С самим asyncio я достаточно давно знаком. Правда, в части клиентских приложений (в т.ч. в связке с aiohttp).
Правильно ли я понимаю, что:
1. Описанный в оригинальной статье httptools в клиентских приложениях поможет не сильно.
2. Вопрос с синхронным dns-резолвером в asyncio/aiohttp все еще открытый (я знаю про aiodns, но подружить их лично у меня не получилось).
Спасибо!
Даёт ли профит в связке с motor/другими асинхронными драйверами БД?
В случае перехода на https-only, как я уже писал выше, блокировать будут по IP. Ну есть еще вариант — MITM-proxy на стороне провайдера, чем он плох, думаю, писать не надо.
Эх, похоже, что скоро нельзя будет пользоваться альтернативными доменами — блочить будут сразу по IP, как это делают со всеми остальными HTTPS-only ресурсами.
multiple content process будет только после релиза первого варианта, т.е. еще очень как не скоро: https://wiki.mozilla.org/Electrolysis/Multiple_content_processes и там блокеров намного больше.
Сам остановился на ACME Tiny (всего 200 строк на python).