Python самый быстрый фреймворк

Самые быстрые Python веб-фреймворки в 2019

В 2018 году Python укрепил свои позиции популярности среди программистов и вошел в Top 3 самых популярных языков на github. Все больше и больше людей переходит на светлую сторону…то есть Python. Появилось еще большее количество разработчиков, которые интересуются данным языком и ведут разработку своих проектов с его помощью. Одним из популярных направлений для Python является web-разработка. Хочется, чтобы не только процесс разработки был удобным и быстрым, но и сами проекты могли похвастаться скоростью и стабильностью работы.

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

Поэтому мы решили составить сравнительный анализ популярных фреймворков, которые не потеряют, мы надеемся, своей актуальности на протяжении всего 2019 года и определить самый быстрый из них.

Участники тестирования

Django

Версия: 2.1.4
Описание: самый популярный комбайн для Python, который из коробки решает множество проблем (админка, авторизация, логирование, ORM, и т.д). Это упрощает жизнь разработчика, но если мы ставим в приоритет скорость работы — то иногда такой комбайн играет против нас и это сказывается на производительности. По этой причине номинацию Fastest Python Web Framework in 2019 он скорее всего не возьмет.

Flask

Версия: 1.0.2
Описание: самый популярный фреймворк на Python (по звездам в GitHub обгоняет даже Django). Популярный выбор в случаях разработки мелких проектов, для которых не нужны те плюшки, которые есть в Django. Позволяет быстро развернуть приложение. Возможно быстрее чем Django по скорости работы, но имеет очень маленькую функциональность “из коробки”.

AioHTTP

Версия: 3.5.1
Описание: очень привлекательный асинхронный Python Framework. Имеет версию клиента и сервера, что значительно развязывает руки при разработке. Обладает очень удобными асинхронными запросами с версии клиента, а также очень хорошие показатели скорости работы сервера при большом количество запросов. Точно должен попасть в тройку лидеров.

Sanic

Версия: 18.12
Описание: можно сказать, что это “многопоточный Flask” со всеми вытекающими. По этой причине мы думаем, что результаты должны быть очень хороши.

Tornado

Версия: 5.1.1
Описание: асинхронный ветеран Python движения, задавший тренд асинхронности в 2010 году. Не теряет своей актуальности и получил 5ю версию в 2018 году. Достаточно высокий порог входа для новичков. Популярен среди олдскульных питонистов, и мы думаем не зря. Должен показать хорошие результаты.

Vibora

Тестируемая версия: релизов на GitHub нет
Описание: многообещающий фреймворк, появившийся в июне 2018 и за последнии полгода набравший более 4000 звезд. Имеет впечатляющие замеры производительности в GitHub. Мы думали именно Vibora станет фаворитом нашей гонки, но к сожалению из-за отсутствия возможности запуска под Python >=3.7 и отсутствия стабильной версии фреймворка мы исключили Vibora.

В GitHub разработчики обещают “кардинально новый” Vibora уже скоро. Посмотрим, что у них получится и обязательно напишем об этом.

Методика тестирования

Тестирование проводилось на Apple iMac 27» Retina 5K 2017, CPU: 3.5GHz i5, RAM: 8GB, 1000GB Fusion Drive, OSX 10.14.2 при помощи утилиты WRK:

wrk -t12 -c400 -d30s http://127.0.0.1:8080/db/

Тесты проводились на Python 3.7.2. Все фреймворки запускались при помощи Gunicorn с двумя воркерами. Возможно в каких-то случаях использование uwsgi сказалось бы на результатах, но так как мы поставили цель тестировать фреймворки, а не способы их запуска — решили этим пренебречь.

У нас был всего один вид тестов: DB Test, в котором мы получаем строковые данные из базы данных и возвращаем их в виде html-ответа (1 запись в 79 bytes). В качестве базы данных использовался Postgres 11. В качестве драйвера обращений к базе использовался psycopg2 в случае синхронных фреймворков и asyncpg в случае асинхронных.

В качестве event loop библиотеки для асинхронных фреймворков решили использовать uvloop.

Результаты

Запросов в секунду

Вполне ожидаемые лидирующие позиции aiohttp и Sanic, но неожиданные результаты от Tornado.

Передача данных в секунду (Кб)

По количеству переданных данных в секунду Django сильно отстает.

Среднее время запроса (мс)

Снова неприятно удивляет Tornado, на который мы изначально делали ставку. Впечатляет Flask, который по среднему времени запроса конкурирует с потенциальными лидерами.

Максимальное время запроса (сек)

Все “подопытные” показали практически одинаковые результаты по максимальному времени запроса. Все, как мы и ожидали.

Финальные результаты

Итоги

Aiohttp: лидер по производительности на начало 2019 года. Если ваша задача требует ультимативной производительности — то стоит к нему присмотреться. К тому же можно поэкспериментировать с параметрами запуска aiohttp, чтобы выжать из него еще больше. Имеет версию клиента, что позволяет без дополнительных библиотек делать асинхронные запросы. Поэтому для реализации своего нового высоконагруженного сервиса мы выбрали его.

Sanic: популярность фреймворка идет впереди его производительности. Чуда не случилось и обогнать лидера не вышло. В совокупности с тредом на Reddit о проблемах c безопасностью — мы бы не стали использовать Sanic прямо сейчас и подождали действий от разработчиков.

Tornado: “разочарование года”. В связи с результатами — не думаем, что Tornado стоит выбирать для реализации каких-либо новых проектов. Надеемся разработчики что-нибудь придумают и исправят ситуацию.

Django показал ожидаемый результат. Мы любим Django за его возможности и избавление нас от рутины, а не за скорость работы. Обширное community, большое количество материалов в Сети, большое количество реализованных проектов в открытом доступе — все это делает его привлекательным для новичков. Если бы у нас стояла задача быстро разработать MVP типичного web-сервиса — мы бы выбрали в 2019 именно его.

Flask тоже показал ожидаемый результат. Обошел Django за счет того, что имеет не такой богатый функционал из коробки. Не дотянул до скорости асинхронных фреймворков. Мы бы выбрали его в 2019 для реализации небольших pet-проектов или тогда, когда уже важна скорость, но разбираться с асинхронными фреймворками желания еще нет.

Все исходные файлы бенчмарков вы можете посмотреть в репозитории Python Frameworks Benchmark.

Источник

Почему не стоит выбирать FastAPI — самый быстрый фреймворк на Python

FastAPI позиционируют как быстрый и легкий фреймворк для создания REST API.

Django представляет из себя довольно громоздкий многофункциональный MVT (MVC) фреймворк. Сам по себе он не совсем предназначен для создания API. Но в совокупности с DRF хорошо справляется со этой задачей.

Изучение нескольких статей о скорости FastAPI натолкнуkо на мысль, что не так все просто.

Я решил разобраться, так ли быстр FastAPI, и стоит ли его выбирать, особенно если пишешь преимущественно на Django.

Для сравнения выбрал критерии:

1. Скорость работы
2. Удобство работы с базой
3. Безопасность
4. Сложность написания приложения
5. Сложность поддержки

Скорость

Для сравнения были подготовлены 2 приложения на FastAPI и Django с максимально близкой логикой.

1. Простой ответ. В ответе json с одним ключом и значением.

2. Асинхронный запрос к другому АПИ, который быстро отвечает. Быстро — это, например, 1 — 5 мс.

3. Асинхронный запрос к другому АПИ, который медленно отвечает. Медленно – это, например, 5 секунд.

Привычные асинхронные запросы aiohttp для обоих фреймворков:

async def request(session): async with session.get(URL) as response: return await response.text() async def task(count): async with aiohttp.ClientSession() as session: tasks = [request(session) for i in range(count)] result = await asyncio.gather(*tasks) 

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

4. Выполнение простой логики. Генерация списка с последующей сортировкой. Количество элементов списка так же передается в аргументах. Эта логика не зависит от фреймворка, но работа фреймворка во время расчета может отличаться.

items = [randrange(100) for i in range(count)] items.sort() 

5. Ответ с синхронным ожиданием. Простой requests:

6. Запрос в базу синхронный.

Для Django через простую модель:

items = MyModel.objects.values()

def get_items(db: Session, skip: int = 0, limit: int = 100): return db.query(models.MyModel).offset(skip).limit(limit).all() items = crud.get_items(db, skip=skip, limit=limit) 

7. Запрос в базу асинхронный (только FastAPI).

async def get_items(db: Session, skip: int = 0, limit: int = 100): res = await db.query(models.MyModel).offset(skip).limit(limit) return res.all() items = await crud.get_items(db, skip=skip, limit=limit) 

Проведение экспериментов

Для проверки использовал обычный ab по 10 вызовов с расчетом среднего. Делал как последовательные запросы, так и параллельные.

Оба приложения были запущены через ASGI.

В результате, как и ожидалось, FastAPI везде отвечал быстрее.

Так как запуски были на ноутбуке, то какого-то объективного абсолютного результата я не ожидал, но сравнение в равных условиях неплохо себя показало.

В таблицах выделены 2 части:

Последовательные запросы генерировались командой:

ab -n 100 http://127.0.0.1:8000/method

ab -n 100 -c 100 http://127.0.0.1:8000/method

При параллельных запроса я брал 80-й процентиль для оценки.

В синхронном режиме работа с базой через ОРМ Django оказалась немного быстрее SQLAlchemy, подключенной к FastAPI. А вот асинхронный режим SQLAlchemy показал себя лучше синхронного Django ORM. Подключать Django в асинхронном режиме не пробовал.

FastAPI выдержала больше одновременных подключений, особенно, при работе с базой. При увеличении количества параллельных запросов FastAPI справлялся лучше, чем Django. Django при количестве параллельных запросов больше 150 уже захлебывался и отбивал ответы.

В итоге FastAPI действительно работает заметно быстрее. По крайней мере, на синтетических запросах.

Многие сравнивают преимущественно скорость, производительность и подобные технические характеристики. Но python чаще используют не там, где нужна высокая скорость и производительность. Его предназначение не в этом. Основные плюсы языка – это хорошая читабельность кода, высокая скорость разработки, широкий выбор инструментов и достаточная производительность. В общем, это не быстрый язык, а удобный. И разница между производительностью фреймворков на реальном коде может быть не такая значительная, чтобы это имело значение. Поэтому сравнение фреймворков по критериям производительности не так сильно влияет на их выбор.

Сложность кода

В Django из коробки уже есть все необходимые инструменты для работы с базой: ORM, миграции, средства отладки. Просто установить, настроить за несколько минут и можно работать. Расширение сервиса на Django вполне понятное и логичное. Можно добавлять модели без особых усилий. В FastAPI нужно подключать внешний ORM и миграции. При разрастании сервиса становится сложнее ориентироваться в нем.

DRF — довольно удобная библиотека, которая умеет работать с моделями Django. Она не совсем из коробки, но подключается достаточно легко.

В FastAPI работа с АПИ встроена по умолчанию. Ничего подключать не надо. Это – плюс. Но работа с сериализаторами, на мой взгляд, чуть более запутана. Хотя это субъективно, а разница – не кардинальна.

Так же в Django есть встроенная удобная админка. Что иногда является плюсом.

Безопасность

Еще должен отметить безопасность фреймворков. В Django из коробки реализована защита от типичных уязвимостей типа CSRF, SQL injection. А вот в FastAPI придется самому решать некоторые вопросы с безопасностью. Как вариант, подключать fastapi.security. Но все равно Django безопаснее.

Вывод

Конечно, создавая небольшие простые приложения и не имея опыта работы с Django, лучше отдать предпочтение FastAPI. Это достаточно небольшой фреймворк, который не придется долго изучать. Но всю необходимую обвязку, не относящуюся непосредственно к фреймворку, изучать все равно придется.

Django же достаточно сложный фреймворк, у него сложнее порог входа, но в нем есть все необходимое. И если вы уже пишите на Django, то FastAPI может показаться сложнее из-за того, что не содержит всех нужных инструментов.

Конечно, вопрос не только в скорости, но и в предпочтениях. В результате оценок я пришел к выводу, что FastAPI на небольшом приложении действительно имеет преимущества перед Django. И для разработки микросервисов точно подойдет. Он немного сложнее в написании кода и поддержке. А вот если нужно писать сложный сервис с большим количеством связей, базой, то я бы выбрал Django. Да он медленнее, но его безопасность, структурированность и большое комьюнити перевешивают производительность FastAPI.

Если же нужно действительно производительное приложение, и скорость важна, то рекомендую обратить внимание на Golang или даже C++, а не Python.

Источник