Если говорить про сам редизайн, то кажется, что дело не только в самом дизайне или адаптированности под Chrome. На вкладке Network браузера можно увидеть много прекрасного вроде периодических ответов на POST-запросы по 10+ секунд при банальном переключении папок.
Вообще говоря, лучше так не писать, за исключением /bin/sh, потому что bash совершенно не обязан лежать в /bin. В той же FreeBSD он ставится из портов совсем не в /bin (возможно, что-то изменилось с моего последнего использования этой системы). А в скриптовых языках вроде python абсолютные пути (помимо того, что бинарь может лежать совершенно не там, где ожидает автор скрипта) еще и ломают virtualenv.
Сделайте пожалуйста https на русском сайте.
В 2016 году для большого интернет-магазина авторизация и передача персональных данных в виде plain text — позор.
Один минус — после этого надо самостоятельно следить и устранять уязвимости как в openssl, так и в nginx.
В идеале, конечно, хорошо бы сделать ppa (если такого еще нет).
Мне сложно судить о реальной потребности в этом со стороны сообщества/разработчиков, я не изучал эту тему очень глубоко.
На трекере asyncio #160 уже достаточно давно открыта, но активности там мало. Еще, как я вижу из changelog еще не выпущенного релиза aiohttp, в будущей версии все же будет поддержка aiodns.
Есть идеи как написать бенчмарк?
М… можно попробовать поднять какой-нибудь hi-perf DNS-сервер вроде Knot DNS и подолбить его запросами.
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 и там блокеров намного больше.
Вообще говоря, лучше так не писать, за исключением
/bin/sh, потому чтоbashсовершенно не обязан лежать в/bin. В той же FreeBSD он ставится из портов совсем не в/bin(возможно, что-то изменилось с моего последнего использования этой системы). А в скриптовых языках вроде python абсолютные пути (помимо того, что бинарь может лежать совершенно не там, где ожидает автор скрипта) еще и ломают virtualenv.Более универсальна форма записи:
В 2016 году для большого интернет-магазина авторизация и передача персональных данных в виде plain text — позор.
В идеале, конечно, хорошо бы сделать ppa (если такого еще нет).
С днем рождения!
И, конечно же, спасибо за этот замечательный проект.
Мне сложно судить о реальной потребности в этом со стороны сообщества/разработчиков, я не изучал эту тему очень глубоко.
На трекере asyncio #160 уже достаточно давно открыта, но активности там мало. Еще, как я вижу из changelog еще не выпущенного релиза aiohttp, в будущей версии все же будет поддержка aiodns.
М… можно попробовать поднять какой-нибудь hi-perf DNS-сервер вроде Knot DNS и подолбить его запросами.
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).