Как стать автором
Обновить

Комментарии 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 и т.п.

Vibora сейчас трогать — грешно. Автор обещает большие изменения, будем надеяться и ждать, но на данный момент, последний коммит — 18 июля. Проблем куча. В продакшн такое не потащишь.

Вот uvicorn / starlette и их друзья — интересные кандидаты. На их основе множество фреймворков наплодилось уже.
Согласен, но выбирали не только на основе производительности, но с учетом зрелости самого фреймворка и личных предпочтений в api. Чтобы не страшно было использовать в продакшене.


В целом, все они выглядят перспективно, мы выработали свой внутренний апи так, чтобы можно было легко скрыть апи конкретного фреймворка. Сейчас нам не трудно будет заменить фреймворк, раньше все было завязано на корутины старого типа.

Всё таки асинхронность к Питону приклеена сбоку на изоленте. Для сетевых сервисов с большой нагрузкой Go, на мой взгляд, гораздо удобнее и быстрее. Хотя и Питон люблю очень, но тут у него всё как-то грустно...

Ну тут надо учесть что Питон как язык существует давно очень и к нему асинхронность дествительно как вы и сказали «приклеивали», Go же создавался изначально уже асинхронным.
Тут надо наверно скорее смотреть в сторону того когда выйдет PHP8 и как там будет работать асинхронность и если в PHP все будет намного лучше чем в Питоне, то тогда например и… говорить о том что Питон не так хорошо работать с асинхронностью.
Так понятно, что наследие влияет. Я говорю с точки зрения практического использования, а не в историческом контексте.

Если у тебя действительно нагруженная система, работающая на многих серверах, то переписав какие-то части на Go ты получишь серьезную экономию ресурсов в итоге. Можно посмотреть примеры Badoo где они переписали что-то с PHP на Go и вместо 30 серверов поставили один.
В ответ на комментарий blind_oracle:

Не согласен.

Без углублений, которые делал автор, всё можно свести к aiohttp + uvloop и async/await синтаксису. Работается с этим крайне просто. :)

Go, конечно, хорош. Мне в первую очередь было интересно: «А как бы показал себя Go в задачах автора?», но когда всё налажено для Питона — переезжать не хочется.
Да, uvloop близок к Go по скорости, согласен.
Точнее говоря близок к стандартной HTTP библиотеке Go, с FastHTTP же легко можно получить 150к+ запросов в секунду.

pyflame на каждой отдельной машинке собираете или есть механизм централизованого сбора в одном месте c ротацией?

У нас запуски pyflame эпизодические, не на постоянной основе. Запускаем на одном-двух контейнерах. Т.е. общий мониторинг производительности централизован и он более высокоуровневый, pyflame для более детальных разборов.
Немного околотопика :)
Имхо для ускорения питона нужно смотреть в сторону C биндингов, чем, собственно, все создатели новых фрэймворков и занимаются. Была интересная презентация от nexedi: они взяли написанный на C http сервер lwan, добавили в свой код ctypes по-максимуму — и получили скорость выше, чем golang с fasthttp
Минус один: на golang можно просто писать и быть уверенным, что код будет работать быстро, питон с обвязкой нужно сначала написать, а потом еще и профилировать

Для своих pet проектов можно еще попробовать Trio – «Pythonic async I/O for humans and snake people». Вот видео презентация от автора: тыц
Зарегистрируйтесь на Хабре , чтобы оставить комментарий