Django или FastAPI - кто быстрее?
HTML-код
- Опубликовано: 19 июл 2024
- Ссылка на репозиторий - github.com/chepe4pi/framework...
В ветках разные варианты приложения. Там же скрипт для генерации большого количества данных.
00:00 Тема урока и обзор приложения
04:00 Скрипт для генерации 1.000.000 записей
06:34 siege - инструмент нагрузочного тестирования
07:45 Django dev server - Нагрузочное тестирование
09:17 Gunicorn 1 worker 1 thread - DRF + ORM Нагрузочное тестирование
12:00 Gunicorn 4 worker 2 thread - DRF
14:15 Function based view без serializers
15:43 Async асинхронная функция вью на Джанго
18:45 Uvicorn - ASGI web server - нагрузим
19:35 asyncio.gather - тестируем асинхронные SQL запросы в базу
24:43 Логирование SQL
25:50 RAW SQL на Django - тестируем запросы на сыром SQL
27:50 FastAPI - тестируем также на RAW SQL
29:24 Сравнение результатов нагрузочного тестирования
32:17 Выводы - какие же писать приложения?
35:05 Вопросы к зрителям
Я поднял свой уровень бэкенда за 35 минут 😁 очень интересна тема оптимизации и нагрузочного тестирования, хочу еще!)
Тема производительности супер интересна, пили ещё плз)
супер)думал попью кофе,посмотрю минут 5-10 и пойду кодить,по итогу все 35 мин просидел)контент пушка
Спасибо!
Благодарю за ваши видео! ждем курс по async и Fastapi
Благодарю за ваши видео! Очень полезно! Интересно все!!! Выпускайте больше и спасибо, что с уважением относитесь к чайникам и объясняете очень добротно и подробно!
yes need course about FastAPI
Был очень рад увидеть сравнение, видно, что вложено немало сил, огромное спасибо за видос!
Лично я пишу на FastAPI, предпочел его из-за быстродействия на слабеньких железках. Да и мне как-то проще писать на нем)
Очень познавательно! Спасибо!
Спасибо Деду!
Пересмотрел все ваши курсы залпом. Узнал очень много мелких тонкостей. Спасибо большое.
Было бы очень посмотреть курсы по асинхронности и по FastAPI.
Огромное спасибо за такой хороший материал и подачу!
Спасибо за просмотры!
Очень крутое, интересное и полезное видео, спасибо!
В целом темы по Django, Fast API и асинхронному Python интересны! :)
Действительно отличное видео! Я думаю многим интересен такой формат, хотелось бы больше подобных видео!
Непонятно почему в качестве базовой метрики был выбран Response time (который среднюю температуру по больнице показывает), а не Transaction rate (кол-во успешных запросов в секунду) или Successful transactions (общее кол-во успешных запросов в минуту).
Очень странная ситуация что кол-во worker'ов для uvicorn не давало прироста, не должно быть так, может упиралось во что-то другое (см. ниже)?
Не раскрыта тема (или я прослушал?) какой драйвер использовался для доступа к БД.
У Django даже в простейшем приложении уже есть дефолтные middleware, их бы тоже в идеале надо бы отключить.
P.S.: логирование запросов может сильно аффектить результат.
P.S.2: спасибо за видео, как начальная точка в замерах очень полезно.
Судя по рекьюретментсам псайкопг он юзал
@@mikeofs1304 для синхронщины нужен соот-й драйвер, psycopg, если не ошибаюсь, чисто синхронный.
Интересно сравнить приложение с логированием с приложением без него) Насколько сильно оно влияет...
Transaction rate в данном случае почти совпадает с Response time, ему пропорционален. По тому что неуспешных трансакций 0.2% - 0.4% , это можно не учитывать, так как тестирование довольно грубое, на домашнем ноуте все-таки.
Кол-во worker'ов для uvicorn , да, во что-то упирается, но пока не понял во что именно. Проверил сейчас с логированием и без, похоже что оно не значительно влияет, разница 1 секунда, что в рамках погрешности от теста к тесту.
Драйвер дефолтный psycopg2-binary, тут ничего не стал менять. Для асинхронного ORM там дефолтный драйвер asyncpg , без него бы aget() и пр. не работали бы.
@@SeniorPomidorDeveloper Фраза @"это в 3 раза быстрее чем самый производительный вариант для Django" была основана как раз на Response time? Но если смотреть, например, по общему кол-ву выполненных запросов то вроде разница уже в 1.5 раза? Тоже здорово, но не 3 все-таки.
Про драйвера ясно, спасибо.
Очень крутое видео! Спасибо!
Да, хотелось бы еще в таком роде
Как всегда лайк - сделано очень продуманно и качественно! Объясняете в меру и не перегружаете инфой. Спасибо Вам за ваш труд!
Сделайте еще видео про генерацию фейковых данных для нагрузочного тестирования, пожалуйста.
Спасибо За видео. Полезно и по формату очень интересно. Единственный нюанс - чуть побольше кегль шрифта.
Учту, спс
Лайк за исследование!
Огромная благодарность за проделанную работу!!!
Видео классное и интересное! Лайк! Голосую за курс по FastAPI
Давайте теперь от вас еще курс по FastApi. Было бы очень круто. Вообще на fastapi все больше вакансий. как считаете django скоро уйдет в прошлое вместе с drf?
Django ещё не скоро уйдёт в прошлое, скажем так Django очень производительный и удобный фреймворк для своих задач, который обрабатывает запросы от сервера и медленнее чем fastApi, но у него есть мощная подкапотка, что позволяет сделать сложный функционал очень быстро, также у него большое комьюнити, как в русском сегменте так и за рубежом, а Fast API, ещё довольно новый фреймворк и уже нашёл свою нишу, он производительный.
Я думаю, что у них разные цели. Django отдает данные во фронт, а FastApi можно использовать тогда, когда данные отдаются большому количеству пользователей, ал-я крипто биржи и пр., когда данными пользуется не человек а боты например. Большая разница плодить кластеры под Django, чтобы отдавать данные в несколько фронтов допустим, или же по минималке отдавать через FastAPI, а там пусть как хотят, так и обрабатывают данные.
Да куда он уйдет.) Нет, когда-то конечно уйдет, но нам с вами хватит)
Сейчас вот глянут статистику сайтов по языкам программирования. 78% существующих сайтов написано на PHP ! До сих пор. Это выглядит чем-то совсем дедовским, но кто-то же их поддерживает.
Каждый инструмент под свои цели. И Джанго уверенно держит свои позиции в нише - комбайн, с помощью которого можно писать что угодно, и не тратить кучу времени на изобретение велосипедов, а брать кучу всего из "коробки".
А вот FastAPI у него другая ниша и он конкурирует скорее с Go и очки не в пользу FastAPI, на мой взгляд.
По этому, я бы тут не загадывал. А изучать асинхронное программирование и FastAPI в том числе, конечно нужно. Я только за.
ДжангА, как и вордпресс будут жить "вечно", собствено как и языки на которых они написаны. Кстати а чатгпт может написать новый ЯП? Что интересно он возьмет за основу?
Не думаю что Гат ГПТ может написать новый ЯП. Да и если бы мог, догадываюсь что это был бы за ЯП, мне уже плакать хочется)
Спасибо. Вот прям шикарные видео и идеи для них
Тема тестирования очень интересна. Мало информации по нему в ютубе. Снимай видео. Очень приятно тебя смотреть
Спасибо!
Спасибо за контент! очень интересно
Спасибо за видео, очень зашло)
Касательно асинк темы - однозначно хочется услышать ваше понимание, сравнить со своим после прочтения книжки Фаулера :)
Рад что видео зашло .
Боюсь что после книжки Фаулера мне не много что будет добавить)
Но как-нибудь надо сделать, тема конечно интересная
Мне как человеку который пишет на спринге было очень интересно послушать,Круто!
Класс! Спринг - сила!
Отличное видео!
Спасибо за качественный контент. Я поднял свои знание. Продолжай в том же духе
Спасибо за видео!
Спасибо за сравнение!
Полезно! Спасибо
крутое видео! спасибо!
Такой Вы хороший человек, спасибо
Очень интересное видео!
уфф какая же имба под вечер
Супер интересно , тоже наверное протестирую
Супер круто. Спасибо
оч интересно , спасибо
Вау круто! Подписка лайк. Ничего не знаю в питоне, от слова 0. Но тут все понял 😂
Буду учить
Ждем курсы по Fastapi, asyncio. Сравнение Fastapi, Esmerald, Starlette, Litestar (нагрузочное тестирование). Спасибо!
Это было реально интересно, спасибо! Единственное, хотелось бы увидеть скорость FastAPI без оптимизаций, но это уже придирки. Видео получилось очень полезным и наглядным. Плюсую к курсу по FastAPI и жду продолжения роликов про производительность!
Да там и не было особо оптимизаций, просто минимальное приложение. Как и на Джанге. Сейчас сделал тест его же на FastAPI + SQLAlchemy и получилось в два раза дольше чем FastAPI + SQL.
@@SeniorPomidorDeveloper сейчас делаю проект FastAPI + MongoDB с использованием Beanie ORM, интересно будет потестить свой проект, какой результат выдаст ))
спасибо большое!
Привет Сеньор помидор=). уважаю тебя, давно смотрю. от тебя заразился так же любовью к макбук и вот купил такой же на 16гБ поставил плагин как у тебя чтобы в трее загрузку по цп и озу видно было)
ну а в целом конечно приятно тебя смотреть и перенимать опыт по джанго-фастапи
Привет! Спасибо за отзыв! Мне пора уже заделаться амбасадором Мака. Почему они мне не платят😆
Классное видео! Было бы интересно увидеть теиу на продакшн сервере как тонко настроить uvucorn и тд для fastapi. С тестированием
больше видео про асинхронность !
Спасибо большое, ценные знания. У вас очень эксклюзивный контент, которые не встретишь нигде. В основном все друг друга повторяют (по крайней мере, в Ютубе).
Что касается темы видео, был удивлен, насколько сильно использование ORM снижает время ответа от сервера. Я так понимаю, Django требуется время чтобы перевести queryset-выражения на sql-выражения, отсюда и разница во времени. Ну а скорость ответа от сервера роли не играет. Даже если страница будет загружаться на 1-2 секунды дольше (а это очень много), большинству пользователей плевать - они даже не заметят. Так что лично я думаю, что удобство и простота разработки важнее для бизнеса, чем оптимизация кода.
И еще где-то читал, что современные приложения (не только веб, а и вообще) оценивают с точки зрения потребления энергии аккумулятора, а не количества времени работы процессора, а это не всегда одно и то же.
Пожалуйста, расскажите подробнее про асинхронность в Django, когда стоит и есть ли вообще смысл использовать sync_to_async и т.д. Успехов в развитии канала 👍
Спасибо большое за такой хороший отзыв!
Да, в таком простейшем сравнении, у меня получились результаты что на 30% или на 0,06 миллисекунд orm увеличивает время ответа. Но надо понимать что реальные запросы в базу как правило сложнее и тяжелее. Если сам запрос выполняется пол секунды, то оверхед, которые накладывает orm уже будет относительно меньше. То есть будет 0,5 сек на запрос плюс те же 0,06 на прослойку orm. Это уже не на 30% увеличение времени , а совсем на малую долю.
Так что да. Это не повод отказываться от ORM, лучше уж тогда от SQL отказываться, тогда реально можно скорость поднять.
Максимально интересно и познавательно, снимай, пожалуйста, еще такого плана видео. Хотелось бы увидеть сравнение python с golang насколько велика разница между ними под нагрузкой. Спасибо!)
Да да! Ты прям угадал тему для следующего видео )
Спасибо!!!
Пасиб за видео! Про асинхронность в джанге интересно) Что реально применимо, а что не очень. И интересно сравнение asyncpg vs psycopg2/3
Да все применимо , было бы желание )
asyncpg vs psycopg2 - там в видео было. По сути все асинхронное ORM идет по asyncpg.
Спасибо
Привет, senior!
1) Спасибо за видео! Очень интересно и полезно!
2) Всё предложенное тобой к тематике следующих видосов - конечно, интересно. Спасибо, что вообще находишь время для таких исследований и делишься ими! Ты крутой!
3) Слышал ли ты что-нибудь о фреймворке LiteStar? Это активно развивающаяся альтернатива FastAPI, но он совсем не раскручен, вакансий не видел по нему. Если "трогал" или видел что-то, очень интересно твое мнение.
Ещё раз спасибо! Всем добра!
Спасибо за такой отзыв!
Сам LiteStar не пробовал. Тут уже несколько раз его советовали. Можно попробовать тоже.
Вообще сейчас появляется много новых фреймворков.
Вот на js, каждый год появляется какой-то модный фреймворк, все начинают свой код переписывать на него, потом проходит год и ситуация повторяется. У нас вот нет такой возможности. Бекенд вообще очень консервативен. 76% сайтов написаны на php, на втором месте стоит C# , куда там до модных фреймворков
пишу! асинхронные вещи, интересно!)
Я ждал еще вариант сравнения c fastapi + sqlalchemy
Да, я уже понял что надо было! )
Сейчас сделал тест FastAPI + SQLAlchemy и получилось в два раза дольше чем FastAPI + SQL.
@@SeniorPomidorDeveloper у алхимии два апи и асинронное значительно быстрее и даже при это ПЛЕВАААТЬ же)) другие условия будут определятЬ. кверибилды юзать в проекте или орм.
Не помню, спрашивал ли у вас, но насколько может быть оправданным использование Джанго для админки сайта, при этом фастапи для написания апи с которым будут быстро взаимодействовать пользователи?
От задачи зависит. Такое может быть оправдано, а может и не быть.
Спасибо за твой труд!
Если есть мысли о курсе по FastAPI, уверен многие его очень оценят!
Хотелось бы услышать твоё мнение о том, как и в каких ситуациях следует разрабатывать бэкенд на том или ином фреймворке, и в целом разбор преимуществ/недостатков каждого из них :)
Хороший вопрос. Не знаю получилось ли бы дать какие-то общие рекомендации, надо подумать.
Часто бывает что бизнес сам не знает какое должно получится приложение, какая и какого типа будет нагрузка и тд. И фреймворк часто выбирается рандомно или по вкусам разработчика.
Спасибо за такое сравнение! Очень было познавательно! Но не хватило сравнения "дефолтной" конструкции Django и "дефолтной" конструкции Fastapi (если конечно у fastapi есть какой-то дефолтный подход к построению запросов и вьюшек аналогично джанге, я не знаток фастапи)
Думаю что такой "дефолтной конструкции" подобно той , которая в Джанго, в FastAPI нету.
Да это не помидор, это Помидоорищеее🎉 лютая годнота
🤣
Джанго медленнее, но все запросы она прогоняет через middleware сессий, аутентификацией, csrf и тд. Если в фастапи делать полноценный сайт со всеми этими функциями, то мб +/- одинаково по скорости будет. Если делать внутренний микросервис, тогда норм
да нужно выкинуть все что не используеться INSTALLED_APPS = ['myapp']
MIDDLEWARE = []
Согласен
Дак в чем проблема сделать и проверить, не чего не будет +/-, откуда такие мысли. Бред какой
Что опять я должен проверять??
Ладно. Проверил. Действительно, без middleware разница не большая, может 15% или даже в пределах погрешности. Если на сервере проверят то можно было бы точнее сказать. Но да, уже видно что middleware не особо влияют
производительность - это супер интересная тема, я на ней завернут
Хочется увидеть разные методы кэширования !
Спасибо за видео!
Если убрать фразу про лаконичность кода (хотя остался вопрос по поводу производительности fastapi не на чистом sql, а с использованием алхимии), то видео выглядит как прогрев перед курсом по fastapi)))
Уже понял что надо было сделать этот тест, все про него спрашивают)
Сейчас сделал тест FastAPI + SQLAlchemy и получилось в два раза дольше чем FastAPI + SQL. Вот как-то так.
Курс по FastAPI не готовится, но кое-что другое будет)
Расскажи отдельно про ассинхронку плиз.
Не могу разделить общей радости от видео.
Что автор пытался донести? Почему в заголовке указано сравнение Django и FastAPI, а на деле их сравнения нет?
1. Ваш код серверов не выполняет абсолютно никакой работы (все то время, что уходило на запрос - это работа базы и сериализатора в одном случае). Что конкретно вы хотели сказать этими цифрами? То, что код в синхронном стиле обрабатывает последовательно запросы, и за счет этого общее время дольше? Но при чем тут Django и FastAPI?
2. Да, было сравнение Django сериализатора с нативным dict. Отлично, но dict же это не фишка FastAPI? А если сравнить, например, с pydantic? Только возьмите JSON большей вложенности.
3. 1m и 100 rps - это очень маленький бенчмарк для сравнения производительности. Для проверки работоспособности - пойдет, но не для сравнения двух технологий. Все выводы, мол "Вариант A быстрее варианта Б в 5 раз" - пустые слова. Сравнивать тут миллисекунды задержек работы базы на рабочем компьютере с множеством других процессов и делать выводы - глупость. Доступ к диску, переключения процессора, а может, у вас оперативка забита и приходится скидывать данные из/в своп и т.д. - все это дает разные цифры, разница в которых и есть "погрешность". Именно для сглаживания этих погрешностей нужно запускать объемные бенчмарки.
4. Последние выводы - это либо тотальная некомпетентность, либо намеренная манипуляция. Слева код из 5 строк, справа 150. А почему бы нам не прибавить к коду слева код моделей? А в коде справа не подключить ORM, что уберет SQL запросы?
Итог: Что сравнивали? Почему так сравнивали? При чем тут вообще FastAPI?
Согласен, особенно посмеялся над выводами. Видео ни о чем
В наши дни любой кто смог написать django-admin startproject начинает считать себя программистом и записывать курсы)
У Джеймса мерфи было сравнение словарей, датаклассов , педантиков и тд. И тп. Разорвали всех атрсы, а педан помоему самым долгим оказался. Ну а этот тест конечно не о чем. Если нет инфраструктуры ток один пк, можно было наверное в виртуальной среде с несколькими виртуалками развернуть
Тред для хейта😀
Постараюсь ответить по делу.
В заголовке указано сравнение Django и FastAPI и сравнение это есть в конце, и в начале я сразу говорю что буду долго оптимизировать вью на Джанго , чтобы их шансы сровнялись. Просто не досмотрели до конца, похоже.
Код действительно не выполняет никакой работы, но в этом и была идея. Протестировать сами фреймворки, какой они накладывают оверхед.
Сравнение сериализаторов и dict, (не самих по себе, а в комплекте с ORM и прочими добавками) в моих тестах, не показало существенной разницы. Видимо узкое горлышко совсем не там.
1m и 100 rps - действительно тест очень быстрый и грубый и дает значительную погрешность. Но для Ютюба приходится делать так, иначе видео было бы видео еще длиннее и сложнее, а вы даже это до конца не досмотрели, судя по тому что пишете что я Django не сравнил с FastAPI.
Код из 5 строк я сравниваю с кодом из 150 строк, для того чтобы показать две крайности. Само собой, в реальной ситуации обычно получается что-то среднее. Я могу конечно, как вы предлагаете, к коду слева прибавить код моделей. А в коде справа подключить ORM. Но тогда вы видео и до середины не досмотрите! Невозможно все вариант рассмотреть, да и не нужно.
Итог. Идея видео была постепенно оптимизировать Джанго и лучший вариант сравнит с FastAPI. Что я и сделал.
@@SeniorPomidorDeveloper
1. Про код и какой оверхед накладываю фреймворки:
Под оверхедом, как я всегда думал, скрывается доп код фреймворков при обработке запросов. Не очень понял что за оверхед FastAPI сравнивается.
2. Про сериализацию и узкое горлышко: на таком тесте с такими простыми данными, запуская в 4 воркера вы и не увидите существенной разницы. Серверу не хватает нагрузки, чтобы показать плохой результат.
3. Про тест и сложность видео: мб стоит подумать над ускорением или вообще убирать из видео работу тестов, оставив только результат. Все же этот вывод терминала вряд ли кто-то читает. Мне кажется, это очень важно, чтобы увеличить нагрузку и проводить тесты на чистой машине, иначе цифры об ускорении в N раз ничего не стоят.
4. Про 5 строк и 150 строк. Но зачем тогда эта манипуляция в выводах, если она не несет никакой полезной нагрузки. Мне казалось вы заинтересованы изложить важные вещи в короткое видео и занимать эфирное время такими "выводами" непозволительная роскошь).
P.s возможно я был резок в первом сообщение, впредь буду подбирать слова мягче. Я не считаю вас "плохим программистом". Вы провели исследование, и за это вам спасибо.
1. Ну у любого фреймворка какой-то оверхед есть , Класс FastAPI() он же не пустой. И метод get() у него, через который пишется вью, тоже совсем не пустой.
2. Так и у реального сервера мы тем более не увидим разницы, как раз по тому что данных будет больше и они будут более связанные и мы раньше упремся в производительность базы, чем почувствуем эти мелочи с сериализатором в сравнении с диктом. Впрочем от приложения зависит. Где-то может и почувствуем, если будем много сериализовывать какие-нибудь быстро доступные данные.
3. Эти цифры, в их абсолютных величинах, действительно ничего не стоят, да и могли бы они что-то стоить? Вроде никто веб-сервера на макбуке не запускает. А в относительных величинах, то есть в соотношении друг-другом, вполне могут быть плюс-минус объективными. Ведь все тесты проводятся в одних и тех же условиях, да машине загружена много чем, записью экрана и тд. Но ведь это для всех тестов актуально. Чтобы это себе доказать, я проводил один и тот же тест несколько раз за время записи видео, и вперемешку с другими тестами, и он всегда выдает одинаковый результат вплоть до секунды.
4. А куда без выводов? Может для вас они не несут никакой полезной нагрузки, но имейте ввиду что большинство из тех кто смотрит, они вообще никогда ничем подобным не занимались. И из результатов видео может создаться ложное впечатление, что FastAPI самый быстрый , значит самый лучший и все нужно писать на нем. А суть выводов что для каждый задачи свое решение и иногда приходится выбирать между простотой кода и быстродействием. Где тут манипуляция? Я не оч понял.
Ну и исследование это конечно, такое себе. Не претендует на объективную истину. Просто хотелось сравнить базовые возможности фреймворков. Если все делать по науке, то тут надо нагружать сервер не одинаковыми запросами, надо добавлять POST и прочее, иметь ввиду что одни запросы запускаются чаще других. Конечно на "реальном железе" надо это делать. И еще много всего. Это такая скорее обзорная экскурсия.
Как вам проводить нагрузочное тестирование между Django Ninja и DRF?
давай про кеширование)
Чертовски интересно послушать про асинхронное джанго и преимущества/недостатки по сравнению со сторонними приложениями типа celery.
Лично я пока не вижу для себя никаких преимуществ, а только кучу геморроя, но я довольно поверхностно знаю питон
Отличное видео и интересная тема, хотелось бы продолжения. И хотел бы спросить твое мнение поводу django ninja, может ли этот фреймворк являться альтернативой fast api или это своего рода франкенштейн? Как бы он себя показал в подобных тестах, так же как fast api или хуже?
Вот надо протестировать! Следующее видео могу с ним сделать
@@SeniorPomidorDeveloper Было бы здорово. Давно слышал о ninja, но не сталкивался, а сейчас смотрю конференцию по django 2024 и там пара спикеров на нем пишут
Можно нагрузку питонячью очень удобно грузить через Locast, тоже удобная библа для таких тестов
👍
🎉
Спасибо за видео.
В конце отсылка к недавно разгоревшемуся холивару "CleanCode VS FastCode"?
Или к давно разгоревшемуся )
Спасибо большое! А вы персональные курсы даёте?
Вот сейчас один курс разрабатываем . На канале будет анонс через пару месяцев
ахуенно. давай курс по FastAPI
Было б интересно еще глянуть сравнения не только фреймворков или языков, но и разных баз данных, к примеру postgres, mysql, sqlite, mongo, clickhouse
response time это конечно хорошо, но разве производительность обычно не в rps мерят? У siege это transaction rate получается. И самый большой получился у обычного gunicorn 4/2 с сериализоторами
Rp/s тут пропорционально практически совпадает с Response time, по-тому что время тестирования для всех одинаковое, а кол-во удачных запросов 99.6% - 99.8% . Для видео в разговорном стиле просто удобнее было говорить про среднее время запроса.
Интересные варианты работы одного и того же приложения. Вариант с FastAPI также надо было сделать с ORM и сериализацией. И тогда сравнить синхронный Django с асинхронным FastAPI. А то получилось, что 5 вариантов на Django и всего 1 вариант на FastAPI.
Потестировал сейчас FastAPI + SQLAlchemy , получилось в два раза дольше чем на сыром SQL. А в Джанго отказ от ORM дает прирост всего на 30%.
Сериализаторы вроде нет разницы особо со словарями. Разница в пределах погрешности.
Как по мне не очень корректно сравнивать такое приложение. В продакшене всегда будут более сложные запросы к базе, что скорее всего даст совершенно другой результат между синк и асинк джангой, соответственно и разницу между фаст апи и джанго. Было бы интересно посмотреть на что-то похожее на продакшен где будут запросы потяжелее, запросов побольше, без чистого sql. А затем ещё сравнить обмазав кешем. Между 0,3 и 0,12 пользователь конечно не заметит скорее всего, но вот поднимать больше подов уже критичнее.
" но вот поднимать больше подов уже критичнее." - почему? Обычно наоборот скейлят не воркерами, а подами. Для более адекватной утилизации времени CPU
Да где же мне взять "что-то похожее на продакшен". Я бы с удовольствием на основе этого видео сделал.
Но тут была цель другая. Протестировать сами фреймворки без всякой внутренней логики, чтобы понять какой они оверхед накладывают. Как они работают в чистом видео. А потом уже адаптировать под свои нужды сможет каждый, но у каждого свои условия и свои запросы.
сделай видео про асинхронные функции
Спасибо большое за видео. Было бы интересно посмотреть похожее тестеравние используя Django Ninja. Автор Фреймворка общает производительность в 3 раза быстрее чем DRF. В теории будет такой же результат как и на FastApi.
Да, хорошая идея для следующего видео!
потому что джанго говно и для асинков форк челы качают )
Хотел бы ещё посмотреть, во-первых кэширование. И фастаип
Так а запросы в бд синхронные же? То есть кажется толькл в 5 django был добавлен pcycopg3, который и сможет позволить делать асинхронные запросы.
В данном этапе получается запросы в бд не делаютсямконкуретно
Так я asyncpg использовал, он как раз асинхронный
но запросы же разные были + в джанге вы циклом проходили еще. Плюс интересно есть ли разница если использовать условный json_agg?
Смотря где. Для sync и async я делал тесты чтобы абсолютно одинаковый был код (кроме конструкции await и того что за ними.)
Разные виды сериализации вроде не особо влияют в этом случае.
@@SeniorPomidorDeveloper в фактах у вас в один запрос, а в Джанго везде два, как то странно сравнивать, когда вы потом это ещё пилоном склеиваете
Если вы имеете ввиду querset в котором prefetch related, то там два запроса . Причем абсолютно такие же как и в других тестах. Не верите - проверьте . Ссылка на репозиторий под видео
@@SeniorPomidorDeveloperАаа, простите, на видео показалось, что на фастах 1 запрос. Тогда да все примерно одинаково.
Хотя, не понятно, почему бы не сделать в один sql если все-равно голый используешь. На работе мне бы на ревью сразу бы сказали в один переписать...))
@AlexeyTeacher это не возможно) когда связь как foreign key то можно сделать join , или он же select related.
Когда это many to many то связь строится через третью таблицу (которая скрыта для Джанго) и тут уже никак без второго запроса не обойтись.
Автору спасибо за труды! Да Джанго медленный, но из коробки он содержит в себе много плюшек. В современном мире наверное важнее время и удобство программиста. А производительность железа периодически удваивается.
Для небольшого интернет магазина/офис солюшена или мвп джанго хорошо подоходит. В большинстве случаев, когда проект +- серьезный рассчитан на среднюю хотя бы нагрузку (100+пользователей) джанго будет проседать, а платить двойные-тройные суммы за доп.интсансы зачем? Да и что из удобства? Админка и генерики встроеные+ мидлтвари, ну оно удобно для совсем тривиальных задач. В большинстве случаев клиенту не хватает админки джанги и просит ее расширять, а это больно, постоянно приходится что-то свое изобретать поверх дженериков джанги либо их переписывать под себя + паттерн актив рекорд, никакую чистую архитектуру нормального не применишь из-за кучи "удобств" встроенных механизмов работы джанго, иными словами большая зависимость от фреймворка и часто это играет в ущерб удобству программисту + более затратно
Мне кажется что главный плюс Джанги это ORM, который по функционалу чуть ли не больше чем весь остальной фреймворк.
Ну и второе очень важное, куча пакетов, которые можно с Джанго использовать. На любую задачу уже есть готовое решение. Иначе все время уйдет на программирование велосипедов, а бизнес этого не любит.
Админка Джанго - вообще барахло, я считаю что от нее лучше сразу избавляться.
А способы оптимизации по сути те же что и в других фреймворках. Кеширование, воркеры и тд.
А платить двойные-тройные суммы за доп.интсансы , на мой взгляд ничего плохого. Дешевле чем платить двойные-тройные суммы нанимая много разработчиков.
@@SeniorPomidorDeveloper проблема орм-а что он основан на актив рекорде, что создает доп нагрузку для программиста и в целом на поддержку проекта(привет паттерн репозиторий) + нет асинк коннекторов к базе
т.е асинк эвейт что сейчас есть по сути бесполезен почти во всех случаях, да для того же фласка и фастапи точно так же есть куча библиотек, скл алхимия не чем не хуже джанговской(по мне так там даже шире функционал), а в некоторых кейсах даже думаю лучше т.к есть четкая модель коммита и того же flush-а. Работал на продукте в месяц на инфру(авс микросервисы) уходило 25к$, узким горлышком была производительность джанги, переписали сервисы на фастапи и сэкономил 7к$, не нанимая никаких новых программистов + получилась чистая архитектура, что гораздо удобнее и гибче нежели типичная джанговская мвс
P.s продакшн развертывание фастапи -
Guinicorn и воркеры ювикорн, так и в самой документации фастапи написано
p.s.s: хотелось бы увидеть тесты на 100/1000/10000 пользователей условно))
Ну само собой, делать микросервисы на Джанго это не лучший вариант. Хотя я с трудом представляю как переход на другой фреймворк мог снизить затраты с 25к$ до 7к$. Там явно что-то еще поменяли.
Про прошакшн развертывание fast API , идея хорошая. Конечно тесты на коленке, на своем ноуте, это все очень приблизительно.
И нагрузка должна в идеале быть более разнообразной. Но 100 клиентов с такой интенсивностью вроде хватило чтобы мой комп нагрузить. Можно проверить, но там у меня уже сокеты в ОС кончаются , ошибки такие падают . Наверное уже другие инструменты нужны и не все на одном компе делать
@@SeniorPomidorDeveloper не, с 25к до 7 это сильно слишком, имел в виду 25-7)
7к экономии в месяц
Не, лучше пили видосы по джанге и оптимизации производительности джанги, ускорение джанги и тд, это очень актуально. Желательно сделать новый курс по асинхронной джанге с каким нибудь мощным проектом
Видос огонь🔥 Спасибо!
Кстати, насколько корректно джанга 4воркера2треда сравнивать с фастапи 8 воркеров
Да фиг знает, просто с разными вариантами эксперементировал)
Асинхронные сервера больше подходят для того чтобы параллельно обрабатывать много запросов. Думаю асинхронный сервер не сильно ухудшится в производительности даже если клиентов будеь в 10-20 раз больше. А вот на счет синхронных серверов я не уверен, думаю они быстро начнут деградировать при таком росте количества одновременных запросов.
У меня и тот и другой деградируют если я скажем в два раза увеличиваю нагрузку. Хотя возможно тут влияет что я тестирую на домашнем ноуте. В следующий раз на мощном сервере попробую
А что за штука справа внизу пайчарма (N/5000M)?
Потребление RAM
Лицо
😁
Что мешает справа написать так же 2 строчки кода на sqlalchemy? + потестить бы скорость сериализации pydantic и в django
Не уместилось уже в видео, и так больше 30 мин, никто досмотреть не может .
@@SeniorPomidorDeveloper если не секрет, какой результат?)
Я имею ввиду что после нескольких часов съемки понял что уже не влазит.
А что мешает вам самому это потестить? Обязательно это должен делать парень из ютюба, пока вы кофе пьете? Быстро за работу!
@@SeniorPomidorDeveloper а как же банальная программистская лень?) лучше спрошу у chatgpt)
🤣
Сделайте пожалуйста видео по ассинхронке
В названии ошибка. Спасибо за видео!
Я один обратил внимание на то, что падает Availability при использовании gunicorn? И повышается количество транзакций.
Доступность 99.6% - 99.8% , я эти десятые процента особо не учитываю. Все таки тесты довольно грубые, на домашнем компе. Был бы сервер, наверное имело бы смысл на них смотреть. А количество транзакций повышается пропорционально среднему времени запроса. Это по сути говорит об одном и том же.
По поводу того что небыло прироста производительности в ассинхронной джанге даже при одновременном выполнении запросов, думаю дело в том что в принципе нет особого смысла в ассинхронном выполнении запросов к бд когда эти запросы выполняются быстро (до 50мс), питон больше ресурсов тратит на ассинхронное выполнение. А вот если бы запросы были бы более "тяжелыми" то тогда был бы другой результат.
Согласен. В идеале надо на реальном приложении тестить и оптимизировать под свои нужны, там где это имеет смысл.
А мне подумалось что более важной цифрой будет как раз следующая строчка "Transaction rate". В том смысле что для общей производительности более важно не время ответа на один запрос - ну действительно открылась страница на 0.05 сек медленнее ну и что - а важнее сколько клиентов сумел обслужить сервер. Да, каждому ответил чуть медленнее, но зато в полтора раза больше клиентов сумели открыть страницу. В принципе эти цифры от теста к тесту так же меняются - место с общем рейтинге не изменится, но увеличение там совсем не такое драматическое. По одному показателю вроде быстрее в три раза, а по другому - было 375 а стало 500 - всего в полтора раза больше транзакций обслужено.
Согласен. Для нагрузочного тестирования эта цифра более важная. Мне уже пишут об этом несколько человек. Для нас разработчиков, более привычная цифра это время ответа от сервера.
Но надо и туда и туда смотреть, это да
Ждал что на 1 000 000 запустишь тест)
Это было бы долго)
Вообще на 1 000 000 , наверное фильтры и поиск надо бы потестировать. Для простого GET на 1 объект, эта цифра наверное не особо влияет
С await gather интересный вариант, но методы не надо создавать внутри других методов, а их следовало объявить за пределами вьюхи. Это и могло замедлить время
Сейчас проверил. Нет. Это не влияет. Разница в десятые процента.
Но ты не учел что в варианте django мы на каждый запрос еще обрабатываем middleware, который за собой на каждый запрос обрабатывает параллельно всю цепочку middleware. А что если вокруг fastapi обернуть эти же процессы middleware (опять же если они необходимы). было бы интересно проверить или выпилить какие-то middleware на стороне django, что бы это было честно.
С уважением Динар)
Привет, Динар!
Я конечно знаю про middleware . Но в этом и была идея , протестовать фреймворки в таком виде, в каком они изначально. Ничего не добавляя и не удаляя. Но для эксперимента конечно надо сделать, проверить какой из них в большей степени замедляет
@@SeniorPomidorDeveloper Крутые выпуски! И главное полезные. Продолжай в том же духе)
было бы круто еще фласк добавить для сравнения
Верхний правый скриншот: все ответы по ~0.01, а один из них аж 6 секунд. Я что-то не понимаю или именно из-за этого долгого ответа средняя 0.30? Мб перепроверить?
Да не. Если там 20.000 запросов , а несколько будет зависать надолго, то все ровно на средний результат это практически не влияет. Там не мало запросов зависает, видимо по тому что ОС перегружена и не хватает чего-то, во что-то упирается . Я перепроверял, разница не большая, два одинаковых теста подряд почти в точности дают одинаковый результат
@@SeniorPomidorDeveloper понял. Справедливо. Хотя странно, что почему-то большая часть запросов достаточно быстро выполняется, а единицы так сильно отстают, создавая погоду среднюю
давай про "асинхронные вещи"
На самом деле сравнивать время ответа конечно можно, но как по мне, куда важнее смотреть на число успешных транзакций. Какой смысл во времени ответа, если количество успешных транзакций(к примеру) будет меньше? Т.е. по факту сервис конечно будет отвечать быстро, но ответ будет, например, будет либо ошибочный, либо не содержащий данные. И да, если так смотреть, то рулит 1ый вариант в случае с Django (gunicorn c 4 воркерами и 2 тредами) и последний с FastAPI.
Тут число успешных транзакций 99.6% - 99.8% , я эти десятые процента особо не учитываю. Все таки тесты довольно грубые, на ноуте рабочем. Много погрешностей в этих расчетах, в любом случае.
Можно ролик про то, как правильно писать views, котороые могут создавать сложные объекты, когда один объект зависит от разных сущьностей, просто как новичку не совсем понятно, как писать такую логику на django?
А зачем писать логику , где один объект зависит от разных сущностей ? )
Допустим бывают случаи, когда мы с помощью переопределения метода perform_create() вытаскиваем user из запроса и связываем его с нашим объектом, а бывают же ситуации, когда помимо user необходимо наш объект связать с ещё какими-то сущностями, где правильно это писать ?
@@commonbro1871 На мой взгляд это не очень важно. По разному делают, бывает во вью, бывает в специальных классах логики.
Пока это просто логика в одном экземпяре, можно оставить во вью. Как только мы что-то подобное должны еще где-то сделать, не копируем ни в коем случае, выносим в отдельный класс или функция и используем ее в двух местах.
Вообще в разных проектах свои стандарты, но по мне так во вью норм, пока кода там не очень много и пока он не копипастится.
мне кажется не совсем корректно код с Джанго орм сравнивать с фастапи на скл- вы бы могли сравнить Джанго орм и приложение фастапи на алхимии - тогда на фастапи код тоже получится скорее всего очень лаконичным нет?)
Ну в этом варианте наверное да, получился бы лаконичным.
Но в больших приложениях на Джанго был бы код более лаконичный, так как там много плюшек из коробки, которые в FastAPI пришлось бы писать и писать.
Сейчас сделал тест FastAPI + SQLAlchemy и получилось в два раза дольше чем FastAPI + SQL.
@@SeniorPomidorDeveloper ого, большое спасибо=) неожидан