Comments 16
Результаты по персентилям времени ответа сервиса
Странный бенчмарк (точнее таблица результатов): разные фреймворки поставлены в разные условия и выдают разные результаты (вот это да!). Все три способа показаны только для rps 1000, остальное не поддается прямому сравнению и приходится додумывать. Вы покажите, как сдуваются фреймворки при больших значениях, зачем вы самое интересное обрезали?
С yield против yield from (он же await) есть такой момент, что yield отдает задачу прямо в планировщик. Если у этой задачи будут свои подзадачи, она их тоже отдаст в планировщик.
В случае же yield from каждая задача отдается на уровень выше, откуда отдается еще уровнем выше и только с самого верхнего уровня попадает в планировщик. И скорость попадания зависит от того, сколько yield from было по пути, то есть от глубины стека. Это можно посмотреть прямо по исходникам питона, то как обрабатывается опкод yield_from. Там действительно все значения, которые илдятся, передаются через все фреймы стека.
Я делал бенчмарки во времена питона 3.5, на питоне 3.7 ничего не поменялось. При уровне вложенности 1 — yield получался быстрее чем yield from в 1,8 раз, а при уровне вложенности 10 — уже в 14 раз. В результате, если у вас развесистая логика с множеством yield from, это может начать тормозить сильнее, чем тестовый пример в котором один уровень вложенности. Плюс сами сетевые функции и фреймворки внутри себя добавляют сколько-то уровней.
Вот тестовый код: https://gist.github.com/homm/2a84341987d20c97615c520af3defaf5
Там же для сравнения кроме yield и yield from есть yield for, это когда итератор итерируется вручную через for. И видно, что такой вариант очень близок к yield from, то есть yield from не оптимизирован как-то отдельно.
Довольно странно читать про выбор асинхронного фреймворка на основе его производительности, но не встретить упоминания sanic, stralette, vibora и т.п.
Вот uvicorn / starlette и их друзья — интересные кандидаты. На их основе множество фреймворков наплодилось уже.
- Sanic: python web server that's written to die fast
- stralette довольно молод
- gihub vibora
Disclaimer: Still at an early stage of development. Rapidly evolving APIs.
В целом, все они выглядят перспективно, мы выработали свой внутренний апи так, чтобы можно было легко скрыть апи конкретного фреймворка. Сейчас нам не трудно будет заменить фреймворк, раньше все было завязано на корутины старого типа.
Всё таки асинхронность к Питону приклеена сбоку на изоленте. Для сетевых сервисов с большой нагрузкой Go, на мой взгляд, гораздо удобнее и быстрее. Хотя и Питон люблю очень, но тут у него всё как-то грустно...
Тут надо наверно скорее смотреть в сторону того когда выйдет PHP8 и как там будет работать асинхронность и если в PHP все будет намного лучше чем в Питоне, то тогда например и… говорить о том что Питон не так хорошо работать с асинхронностью.
Если у тебя действительно нагруженная система, работающая на многих серверах, то переписав какие-то части на Go ты получишь серьезную экономию ресурсов в итоге. Можно посмотреть примеры Badoo где они переписали что-то с PHP на Go и вместо 30 серверов поставили один.
Не согласен.
Без углублений, которые делал автор, всё можно свести к aiohttp + uvloop и async/await синтаксису. Работается с этим крайне просто. :)
Go, конечно, хорош. Мне в первую очередь было интересно: «А как бы показал себя Go в задачах автора?», но когда всё налажено для Питона — переезжать не хочется.
pyflame
на каждой отдельной машинке собираете или есть механизм централизованого сбора в одном месте c ротацией?
Имхо для ускорения питона нужно смотреть в сторону C биндингов, чем, собственно, все создатели новых фрэймворков и занимаются. Была интересная презентация от nexedi: они взяли написанный на C http сервер lwan, добавили в свой код ctypes по-максимуму — и получили скорость выше, чем golang с fasthttp
Минус один: на golang можно просто писать и быть уверенным, что код будет работать быстро, питон с обвязкой нужно сначала написать, а потом еще и профилировать
Для своих pet проектов можно еще попробовать Trio – «Pythonic async I/O for humans and snake people». Вот видео презентация от автора: тыц
Tornado vs Aiohttp: путешествие в дебри асинхронных фреймворков