Django или FastAPI - кто быстрее?

[@nvkey]

Я поднял свой уровень бэкенда за 35 минут 😁 очень интересна тема оптимизации и нагрузочного тестирования, хочу еще!)

[@AlekseiMishin]

Тема производительности супер интересна, пили ещё плз)

[@MynameLotus-y4b]

Благодарю за ваши видео! ждем курс по async и Fastapi

[@lightgod4669]

супер)думал попью кофе,посмотрю минут 5-10 и пойду кодить,по итогу все 35 мин просидел)контент пушка

[@SeniorPomidorDeveloper]

Спасибо!

[@oldcoders]

Очень познавательно! Спасибо!

[@SeniorPomidorDeveloper]

Спасибо Деду!

[@Rasty_Boss]

yes need course about FastAPI

[@Jenny-so-it]

Благодарю за ваши видео! Очень полезно! Интересно все!!! Выпускайте больше и спасибо, что с уважением относитесь к чайникам и объясняете очень добротно и подробно!

[@sinya_dev]

Был очень рад увидеть сравнение, видно, что вложено немало сил, огромное спасибо за видос! Лично я пишу на FastAPI, предпочел его из-за быстродействия на слабеньких железках. Да и мне как-то проще писать на нем)

[@ЛитровыйглотокНаночь]

Пересмотрел все ваши курсы залпом. Узнал очень много мелких тонкостей. Спасибо большое. Было бы очень посмотреть курсы по асинхронности и по FastAPI. Огромное спасибо за такой хороший материал и подачу!

[@SeniorPomidorDeveloper]

Спасибо за просмотры!

[@МаксимГалкин-э5р]

Было очень интересно!Большое спасибо за сравнительный анализ!Результаты теста превзошли мои ожидания.

[@sachivkin]

Очень крутое, интересное и полезное видео, спасибо! В целом темы по Django, Fast API и асинхронному Python интересны! :)

[@andreyp5764]

Непонятно почему в качестве базовой метрики был выбран Response time (который среднюю температуру по больнице показывает), а не Transaction rate (кол-во успешных запросов в секунду) или Successful transactions (общее кол-во успешных запросов в минуту). Очень странная ситуация что кол-во worker'ов для uvicorn не давало прироста, не должно быть так, может упиралось во что-то другое (см. ниже)? Не раскрыта тема (или я прослушал?) какой драйвер использовался для доступа к БД. У Django даже в простейшем приложении уже есть дефолтные middleware, их бы тоже в идеале надо бы отключить. P.S.: логирование запросов может сильно аффектить результат. P.S.2: спасибо за видео, как начальная точка в замерах очень полезно.

[@mikeofs1304]

Судя по рекьюретментсам псайкопг он юзал

[@andreyp5764]

@@mikeofs1304 для синхронщины нужен соот-й драйвер, psycopg, если не ошибаюсь, чисто синхронный.

[@the_huge_knight]

Интересно сравнить приложение с логированием с приложением без него) Насколько сильно оно влияет...

[@SeniorPomidorDeveloper]

Transaction rate в данном случае почти совпадает с Response time, ему пропорционален. По тому что неуспешных трансакций 0.2% - 0.4% , это можно не учитывать, так как тестирование довольно грубое, на домашнем ноуте все-таки. Кол-во worker'ов для uvicorn , да, во что-то упирается, но пока не понял во что именно. Проверил сейчас с логированием и без, похоже что оно не значительно влияет, разница 1 секунда, что в рамках погрешности от теста к тесту. Драйвер дефолтный psycopg2-binary, тут ничего не стал менять. Для асинхронного ORM там дефолтный драйвер asyncpg , без него бы aget() и пр. не работали бы.

[@andreyp5764]

@@SeniorPomidorDeveloper Фраза @"это в 3 раза быстрее чем самый производительный вариант для Django" была основана как раз на Response time? Но если смотреть, например, по общему кол-ву выполненных запросов то вроде разница уже в 1.5 раза? Тоже здорово, но не 3 все-таки. Про драйвера ясно, спасибо.

[@sviteribuben7245]

Спасибо За видео. Полезно и по формату очень интересно. Единственный нюанс - чуть побольше кегль шрифта.

[@SeniorPomidorDeveloper]

Учту, спс

[@Jason-lk6gb]

Давайте теперь от вас еще курс по FastApi. Было бы очень круто. Вообще на fastapi все больше вакансий. как считаете django скоро уйдет в прошлое вместе с drf?

[@mylife-ej8et]

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

[@marvillbarrow3375]

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

[@SeniorPomidorDeveloper]

Да куда он уйдет.) Нет, когда-то конечно уйдет, но нам с вами хватит) Сейчас вот глянут статистику сайтов по языкам программирования. 78% существующих сайтов написано на PHP ! До сих пор. Это выглядит чем-то совсем дедовским, но кто-то же их поддерживает. Каждый инструмент под свои цели. И Джанго уверенно держит свои позиции в нише - комбайн, с помощью которого можно писать что угодно, и не тратить кучу времени на изобретение велосипедов, а брать кучу всего из "коробки". А вот FastAPI у него другая ниша и он конкурирует скорее с Go и очки не в пользу FastAPI, на мой взгляд. По этому, я бы тут не загадывал. А изучать асинхронное программирование и FastAPI в том числе, конечно нужно. Я только за.

[@AlexandrStepanov-y4g]

ДжангА, как и вордпресс будут жить "вечно", собствено как и языки на которых они написаны. Кстати а чатгпт может написать новый ЯП? Что интересно он возьмет за основу?

[@SeniorPomidorDeveloper]

Не думаю что Гат ГПТ может написать новый ЯП. Да и если бы мог, догадываюсь что это был бы за ЯП, мне уже плакать хочется)

[@pytag6548]

Ждем курсы по Fastapi, asyncio. Сравнение Fastapi, Esmerald, Starlette, Litestar (нагрузочное тестирование). Спасибо!

[@forest_1771]

Действительно отличное видео! Я думаю многим интересен такой формат, хотелось бы больше подобных видео!

[@goblingo9042]

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

[@АндрейБурчик-й3е]

за 35 минут узнал больше чем за все время изучения

[@bernardsoul8936]

Видео классное и интересное! Лайк! Голосую за курс по FastAPI

[@goro2120]

Мне как человеку который пишет на спринге было очень интересно послушать,Круто!

[@SeniorPomidorDeveloper]

Класс! Спринг - сила!

[@Rulezzz3]

Тема тестирования очень интересна. Мало информации по нему в ютубе. Снимай видео. Очень приятно тебя смотреть

[@SeniorPomidorDeveloper]

Спасибо!

[@davidsaidov8308]

Было очень интересно, спасибо!

[@ЭркинМамадиев]

Спасибо за качественный контент. Я поднял свои знание. Продолжай в том же духе

[@romansozinov]

Лайк за исследование!

[@npc-r390]

Джанго медленнее, но все запросы она прогоняет через middleware сессий, аутентификацией, csrf и тд. Если в фастапи делать полноценный сайт со всеми этими функциями, то мб +/- одинаково по скорости будет. Если делать внутренний микросервис, тогда норм

[@valentynmalyi]

да нужно выкинуть все что не используеться INSTALLED_APPS = ['myapp'] MIDDLEWARE = []

[@SeniorPomidorDeveloper]

Согласен

[@MrEligos]

Дак в чем проблема сделать и проверить, не чего не будет +/-, откуда такие мысли. Бред какой

[@SeniorPomidorDeveloper]

Что опять я должен проверять??

[@SeniorPomidorDeveloper]

Ладно. Проверил. Действительно, без middleware разница не большая, может 15% или даже в пределах погрешности. Если на сервере проверят то можно было бы точнее сказать. Но да, уже видно что middleware не особо влияют

[@temirlllan]

больше видео про асинхронность !

[@qqme1860]

Не могу разделить общей радости от видео. Что автор пытался донести? Почему в заголовке указано сравнение Django и FastAPI, а на деле их сравнения нет? 1. Ваш код серверов не выполняет абсолютно никакой работы (все то время, что уходило на запрос - это работа базы и сериализатора в одном случае). Что конкретно вы хотели сказать этими цифрами? То, что код в синхронном стиле обрабатывает последовательно запросы, и за счет этого общее время дольше? Но при чем тут Django и FastAPI? 2. Да, было сравнение Django сериализатора с нативным dict. Отлично, но dict же это не фишка FastAPI? А если сравнить, например, с pydantic? Только возьмите JSON большей вложенности. 3. 1m и 100 rps - это очень маленький бенчмарк для сравнения производительности. Для проверки работоспособности - пойдет, но не для сравнения двух технологий. Все выводы, мол "Вариант A быстрее варианта Б в 5 раз" - пустые слова. Сравнивать тут миллисекунды задержек работы базы на рабочем компьютере с множеством других процессов и делать выводы - глупость. Доступ к диску, переключения процессора, а может, у вас оперативка забита и приходится скидывать данные из/в своп и т.д. - все это дает разные цифры, разница в которых и есть "погрешность". Именно для сглаживания этих погрешностей нужно запускать объемные бенчмарки. 4. Последние выводы - это либо тотальная некомпетентность, либо намеренная манипуляция. Слева код из 5 строк, справа 150. А почему бы нам не прибавить к коду слева код моделей? А в коде справа не подключить ORM, что уберет SQL запросы? Итог: Что сравнивали? Почему так сравнивали? При чем тут вообще FastAPI?

[@Матвей-н7ф5о]

Согласен, особенно посмеялся над выводами. Видео ни о чем В наши дни любой кто смог написать django-admin startproject начинает считать себя программистом и записывать курсы)

[@mikeofs1304]

У Джеймса мерфи было сравнение словарей, датаклассов , педантиков и тд. И тп. Разорвали всех атрсы, а педан помоему самым долгим оказался. Ну а этот тест конечно не о чем. Если нет инфраструктуры ток один пк, можно было наверное в виртуальной среде с несколькими виртуалками развернуть

[@SeniorPomidorDeveloper]

Тред для хейта😀 Постараюсь ответить по делу. В заголовке указано сравнение Django и FastAPI и сравнение это есть в конце, и в начале я сразу говорю что буду долго оптимизировать вью на Джанго , чтобы их шансы сровнялись. Просто не досмотрели до конца, похоже. Код действительно не выполняет никакой работы, но в этом и была идея. Протестировать сами фреймворки, какой они накладывают оверхед. Сравнение сериализаторов и dict, (не самих по себе, а в комплекте с ORM и прочими добавками) в моих тестах, не показало существенной разницы. Видимо узкое горлышко совсем не там. 1m и 100 rps - действительно тест очень быстрый и грубый и дает значительную погрешность. Но для Ютюба приходится делать так, иначе видео было бы видео еще длиннее и сложнее, а вы даже это до конца не досмотрели, судя по тому что пишете что я Django не сравнил с FastAPI. Код из 5 строк я сравниваю с кодом из 150 строк, для того чтобы показать две крайности. Само собой, в реальной ситуации обычно получается что-то среднее. Я могу конечно, как вы предлагаете, к коду слева прибавить код моделей. А в коде справа подключить ORM. Но тогда вы видео и до середины не досмотрите! Невозможно все вариант рассмотреть, да и не нужно. Итог. Идея видео была постепенно оптимизировать Джанго и лучший вариант сравнит с FastAPI. Что я и сделал.

[@qqme1860]

​@@SeniorPomidorDeveloper 1. Про код и какой оверхед накладываю фреймворки: Под оверхедом, как я всегда думал, скрывается доп код фреймворков при обработке запросов. Не очень понял что за оверхед FastAPI сравнивается. 2. Про сериализацию и узкое горлышко: на таком тесте с такими простыми данными, запуская в 4 воркера вы и не увидите существенной разницы. Серверу не хватает нагрузки, чтобы показать плохой результат. 3. Про тест и сложность видео: мб стоит подумать над ускорением или вообще убирать из видео работу тестов, оставив только результат. Все же этот вывод терминала вряд ли кто-то читает. Мне кажется, это очень важно, чтобы увеличить нагрузку и проводить тесты на чистой машине, иначе цифры об ускорении в N раз ничего не стоят. 4. Про 5 строк и 150 строк. Но зачем тогда эта манипуляция в выводах, если она не несет никакой полезной нагрузки. Мне казалось вы заинтересованы изложить важные вещи в короткое видео и занимать эфирное время такими "выводами" непозволительная роскошь). P.s возможно я был резок в первом сообщение, впредь буду подбирать слова мягче. Я не считаю вас "плохим программистом". Вы провели исследование, и за это вам спасибо.

[@SeniorPomidorDeveloper]

1. Ну у любого фреймворка какой-то оверхед есть , Класс FastAPI() он же не пустой. И метод get() у него, через который пишется вью, тоже совсем не пустой. 2. Так и у реального сервера мы тем более не увидим разницы, как раз по тому что данных будет больше и они будут более связанные и мы раньше упремся в производительность базы, чем почувствуем эти мелочи с сериализатором в сравнении с диктом. Впрочем от приложения зависит. Где-то может и почувствуем, если будем много сериализовывать какие-нибудь быстро доступные данные. 3. Эти цифры, в их абсолютных величинах, действительно ничего не стоят, да и могли бы они что-то стоить? Вроде никто веб-сервера на макбуке не запускает. А в относительных величинах, то есть в соотношении друг-другом, вполне могут быть плюс-минус объективными. Ведь все тесты проводятся в одних и тех же условиях, да машине загружена много чем, записью экрана и тд. Но ведь это для всех тестов актуально. Чтобы это себе доказать, я проводил один и тот же тест несколько раз за время записи видео, и вперемешку с другими тестами, и он всегда выдает одинаковый результат вплоть до секунды. 4. А куда без выводов? Может для вас они не несут никакой полезной нагрузки, но имейте ввиду что большинство из тех кто смотрит, они вообще никогда ничем подобным не занимались. И из результатов видео может создаться ложное впечатление, что FastAPI самый быстрый , значит самый лучший и все нужно писать на нем. А суть выводов что для каждый задачи свое решение и иногда приходится выбирать между простотой кода и быстродействием. Где тут манипуляция? Я не оч понял. Ну и исследование это конечно, такое себе. Не претендует на объективную истину. Просто хотелось сравнить базовые возможности фреймворков. Если все делать по науке, то тут надо нагружать сервер не одинаковыми запросами, надо добавлять POST и прочее, иметь ввиду что одни запросы запускаются чаще других. Конечно на "реальном железе" надо это делать. И еще много всего. Это такая скорее обзорная экскурсия.

[@VictorPriyma]

Огромная благодарность за проделанную работу!!!

[@constantinemalykhin]

Очень крутое видео! Спасибо! Да, хотелось бы еще в таком роде

[@Spaut]

Я ждал еще вариант сравнения c fastapi + sqlalchemy

[@SeniorPomidorDeveloper]

Да, я уже понял что надо было! ) Сейчас сделал тест FastAPI + SQLAlchemy и получилось в два раза дольше чем FastAPI + SQL.

[@madex4336]

@@SeniorPomidorDeveloper у алхимии два апи и асинронное значительно быстрее и даже при это ПЛЕВАААТЬ же)) другие условия будут определятЬ. кверибилды юзать в проекте или орм.

[@xizlt]

Спасибо. Вот прям шикарные видео и идеи для них

[@bvkiposs]

уфф какая же имба под вечер

[@ДавидЛазаров-т8ц]

Вау круто! Подписка лайк. Ничего не знаю в питоне, от слова 0. Но тут все понял 😂 Буду учить

[@ZZZMerk]

Спасибо за видео, очень зашло) Касательно асинк темы - однозначно хочется услышать ваше понимание, сравнить со своим после прочтения книжки Фаулера :)

[@SeniorPomidorDeveloper]

Рад что видео зашло . Боюсь что после книжки Фаулера мне не много что будет добавить) Но как-нибудь надо сделать, тема конечно интересная

[@kopo4yh469]

Да это не помидор, это Помидоорищеее🎉 лютая годнота

[@SeniorPomidorDeveloper]

🤣

[@deffunction7657]

Такой Вы хороший человек, спасибо

[@АлексейКомаров-ф8к]

Спасибо большое, ценные знания. У вас очень эксклюзивный контент, которые не встретишь нигде. В основном все друг друга повторяют (по крайней мере, в Ютубе). Что касается темы видео, был удивлен, насколько сильно использование ORM снижает время ответа от сервера. Я так понимаю, Django требуется время чтобы перевести queryset-выражения на sql-выражения, отсюда и разница во времени. Ну а скорость ответа от сервера роли не играет. Даже если страница будет загружаться на 1-2 секунды дольше (а это очень много), большинству пользователей плевать - они даже не заметят. Так что лично я думаю, что удобство и простота разработки важнее для бизнеса, чем оптимизация кода. И еще где-то читал, что современные приложения (не только веб, а и вообще) оценивают с точки зрения потребления энергии аккумулятора, а не количества времени работы процессора, а это не всегда одно и то же. Пожалуйста, расскажите подробнее про асинхронность в Django, когда стоит и есть ли вообще смысл использовать sync_to_async и т.д. Успехов в развитии канала 👍

[@SeniorPomidorDeveloper]

Спасибо большое за такой хороший отзыв! Да, в таком простейшем сравнении, у меня получились результаты что на 30% или на 0,06 миллисекунд orm увеличивает время ответа. Но надо понимать что реальные запросы в базу как правило сложнее и тяжелее. Если сам запрос выполняется пол секунды, то оверхед, которые накладывает orm уже будет относительно меньше. То есть будет 0,5 сек на запрос плюс те же 0,06 на прослойку orm. Это уже не на 30% увеличение времени , а совсем на малую долю. Так что да. Это не повод отказываться от ORM, лучше уж тогда от SQL отказываться, тогда реально можно скорость поднять.

[@АндрейКомиссаров-д3ц]

Очень интересное видео!

[@gnjjnhfc]

Классное видео! Было бы интересно увидеть теиу на продакшн сервере как тонко настроить uvucorn и тд для fastapi. С тестированием

[@sleepmode7592]

Максимально интересно и познавательно, снимай, пожалуйста, еще такого плана видео. Хотелось бы увидеть сравнение python с golang насколько велика разница между ними под нагрузкой. Спасибо!)

[@SeniorPomidorDeveloper]

Да да! Ты прям угадал тему для следующего видео )

[@ВасилийСоло]

Как по мне не очень корректно сравнивать такое приложение. В продакшене всегда будут более сложные запросы к базе, что скорее всего даст совершенно другой результат между синк и асинк джангой, соответственно и разницу между фаст апи и джанго. Было бы интересно посмотреть на что-то похожее на продакшен где будут запросы потяжелее, запросов побольше, без чистого sql. А затем ещё сравнить обмазав кешем. Между 0,3 и 0,12 пользователь конечно не заметит скорее всего, но вот поднимать больше подов уже критичнее.

[@agentdaun5699]

" но вот поднимать больше подов уже критичнее." - почему? Обычно наоборот скейлят не воркерами, а подами. Для более адекватной утилизации времени CPU

[@SeniorPomidorDeveloper]

Да где же мне взять "что-то похожее на продакшен". Я бы с удовольствием на основе этого видео сделал. Но тут была цель другая. Протестировать сами фреймворки без всякой внутренней логики, чтобы понять какой они оверхед накладывают. Как они работают в чистом видео. А потом уже адаптировать под свои нужды сможет каждый, но у каждого свои условия и свои запросы.

[@vegzuzvegzuz2866]

Отличное видео!

[@sleepmode7592]

Было б интересно еще глянуть сравнения не только фреймворков или языков, но и разных баз данных, к примеру postgres, mysql, sqlite, mongo, clickhouse

[@RomaCostin]

ахуенно. давай курс по FastAPI

[@11kapitan1]

Супер интересно , тоже наверное протестирую

[@ragimov700]

Это было реально интересно, спасибо! Единственное, хотелось бы увидеть скорость FastAPI без оптимизаций, но это уже придирки. Видео получилось очень полезным и наглядным. Плюсую к курсу по FastAPI и жду продолжения роликов про производительность!

[@SeniorPomidorDeveloper]

Да там и не было особо оптимизаций, просто минимальное приложение. Как и на Джанге. Сейчас сделал тест его же на FastAPI + SQLAlchemy и получилось в два раза дольше чем FastAPI + SQL.

[@antont5229]

​@@SeniorPomidorDeveloper сейчас делаю проект FastAPI + MongoDB с использованием Beanie ORM, интересно будет потестить свой проект, какой результат выдаст ))

[@ИсраилБ]

Спасибо за видео!

[@АлександрДергилёв-п8х]

Полезно! Спасибо

[@antonromanov4554]

оч интересно , спасибо

[@mellonface5280]

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

[@SeniorPomidorDeveloper]

У меня и тот и другой деградируют если я скажем в два раза увеличиваю нагрузку. Хотя возможно тут влияет что я тестирую на домашнем ноуте. В следующий раз на мощном сервере попробую

[@KUBD996]

Спасибо за ролик! Очень информативно. Можно тесты разных базы данных?

[@SeniorPomidorDeveloper]

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

[@KUBD996]

@@SeniorPomidorDeveloper окей

[@andyabsent4648]

Супер круто. Спасибо

[@ХанаМ]

Спасибо!!!

[@the_huge_knight]

Интересные варианты работы одного и того же приложения. Вариант с FastAPI также надо было сделать с ORM и сериализацией. И тогда сравнить синхронный Django с асинхронным FastAPI. А то получилось, что 5 вариантов на Django и всего 1 вариант на FastAPI.

[@SeniorPomidorDeveloper]

Потестировал сейчас FastAPI + SQLAlchemy , получилось в два раза дольше чем на сыром SQL. А в Джанго отказ от ORM дает прирост всего на 30%.

[@SeniorPomidorDeveloper]

Сериализаторы вроде нет разницы особо со словарями. Разница в пределах погрешности.

[@Katar1x]

давай про кеширование)

[@MER1D1AN]

Хотел бы ещё посмотреть, во-первых кэширование. И фастаип

[@Jastcher]

Пасиб за видео! Про асинхронность в джанге интересно) Что реально применимо, а что не очень. И интересно сравнение asyncpg vs psycopg2/3

[@SeniorPomidorDeveloper]

Да все применимо , было бы желание ) asyncpg vs psycopg2 - там в видео было. По сути все асинхронное ORM идет по asyncpg.

[@runderoy6650]

Спасибо за твой труд! Если есть мысли о курсе по FastAPI, уверен многие его очень оценят! Хотелось бы услышать твоё мнение о том, как и в каких ситуациях следует разрабатывать бэкенд на том или ином фреймворке, и в целом разбор преимуществ/недостатков каждого из них :)

[@SeniorPomidorDeveloper]

Хороший вопрос. Не знаю получилось ли бы дать какие-то общие рекомендации, надо подумать. Часто бывает что бизнес сам не знает какое должно получится приложение, какая и какого типа будет нагрузка и тд. И фреймворк часто выбирается рандомно или по вкусам разработчика.

[@GalimovBulat]

Интересно на сколько бы стал медленнее FastAPI с SQLAlchemy? Не хватило этого момента конечно +) Да, и курс по FastAPI было бы интересно посмотреть. Спасибо!

[@Play-fs9gv]

А мне подумалось что более важной цифрой будет как раз следующая строчка "Transaction rate". В том смысле что для общей производительности более важно не время ответа на один запрос - ну действительно открылась страница на 0.05 сек медленнее ну и что - а важнее сколько клиентов сумел обслужить сервер. Да, каждому ответил чуть медленнее, но зато в полтора раза больше клиентов сумели открыть страницу. В принципе эти цифры от теста к тесту так же меняются - место с общем рейтинге не изменится, но увеличение там совсем не такое драматическое. По одному показателю вроде быстрее в три раза, а по другому - было 375 а стало 500 - всего в полтора раза больше транзакций обслужено.

[@SeniorPomidorDeveloper]

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

[@mrfreeman2536]

пишу! асинхронные вещи, интересно!)

[@stiker7778]

Хочется увидеть разные методы кэширования !

[@Айти_брат]

Привет Сеньор помидор=). уважаю тебя, давно смотрю. от тебя заразился так же любовью к макбук и вот купил такой же на 16гБ поставил плагин как у тебя чтобы в трее загрузку по цп и озу видно было) ну а в целом конечно приятно тебя смотреть и перенимать опыт по джанго-фастапи

[@SeniorPomidorDeveloper]

Привет! Спасибо за отзыв! Мне пора уже заделаться амбасадором Мака. Почему они мне не платят😆

[@MrNagios]

производительность - это супер интересная тема, я на ней завернут

[@the_codest]

Привет, senior! 1) Спасибо за видео! Очень интересно и полезно! 2) Всё предложенное тобой к тематике следующих видосов - конечно, интересно. Спасибо, что вообще находишь время для таких исследований и делишься ими! Ты крутой! 3) Слышал ли ты что-нибудь о фреймворке LiteStar? Это активно развивающаяся альтернатива FastAPI, но он совсем не раскручен, вакансий не видел по нему. Если "трогал" или видел что-то, очень интересно твое мнение. Ещё раз спасибо! Всем добра!

[@SeniorPomidorDeveloper]

Спасибо за такой отзыв! Сам LiteStar не пробовал. Тут уже несколько раз его советовали. Можно попробовать тоже. Вообще сейчас появляется много новых фреймворков. Вот на js, каждый год появляется какой-то модный фреймворк, все начинают свой код переписывать на него, потом проходит год и ситуация повторяется. У нас вот нет такой возможности. Бекенд вообще очень консервативен. 76% сайтов написаны на php, на втором месте стоит C# , куда там до модных фреймворков

[@markjulian2912]

А можно гайд по удаленному хранению статики и медиа, то есть хороший такой гайд по django-storages. В интернете оч мало информации по тому как сделать удаленное хранилище и передавать файлы статики например по sftp. Залайкайте пожалуйста, на ютубе не нашел такого контента:(

[@SeniorPomidorDeveloper]

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

[@stiker7778]

Можно нагрузку питонячью очень удобно грузить через Locast, тоже удобная библа для таких тестов

[@Фома-ж7я]

Спасибо за видео! Если убрать фразу про лаконичность кода (хотя остался вопрос по поводу производительности fastapi не на чистом sql, а с использованием алхимии), то видео выглядит как прогрев перед курсом по fastapi)))

[@SeniorPomidorDeveloper]

Уже понял что надо было сделать этот тест, все про него спрашивают) Сейчас сделал тест FastAPI + SQLAlchemy и получилось в два раза дольше чем FastAPI + SQL. Вот как-то так. Курс по FastAPI не готовится, но кое-что другое будет)

[@HumoyunAhmedov-g9r]

Как вам проводить нагрузочное тестирование между Django Ninja и DRF?

[@r.chitector]

Спасибо за такое сравнение! Очень было познавательно! Но не хватило сравнения "дефолтной" конструкции Django и "дефолтной" конструкции Fastapi (если конечно у fastapi есть какой-то дефолтный подход к построению запросов и вьюшек аналогично джанге, я не знаток фастапи)

[@SeniorPomidorDeveloper]

Думаю что такой "дефолтной конструкции" подобно той , которая в Джанго, в FastAPI нету.

[@marvillbarrow3375]

Я один обратил внимание на то, что падает Availability при использовании gunicorn? И повышается количество транзакций.

[@SeniorPomidorDeveloper]

Доступность 99.6% - 99.8% , я эти десятые процента особо не учитываю. Все таки тесты довольно грубые, на домашнем компе. Был бы сервер, наверное имело бы смысл на них смотреть. А количество транзакций повышается пропорционально среднему времени запроса. Это по сути говорит об одном и том же.

[@СвятославМамзин]

По поводу того что небыло прироста производительности в ассинхронной джанге даже при одновременном выполнении запросов, думаю дело в том что в принципе нет особого смысла в ассинхронном выполнении запросов к бд когда эти запросы выполняются быстро (до 50мс), питон больше ресурсов тратит на ассинхронное выполнение. А вот если бы запросы были бы более "тяжелыми" то тогда был бы другой результат.

[@SeniorPomidorDeveloper]

Согласен. В идеале надо на реальном приложении тестить и оптимизировать под свои нужны, там где это имеет смысл.

[@liopox_]

24:25 Да, асинхронность помогает когда эти запросы работают не мгновенно, например, если бд развернуто на другом сервере и есть хоть какой-то пинг.

[@liopox_]

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

[@SeniorPomidorDeveloper]

База замедляет асинхронный код в той же мере что и синхронный. Разве нет? В любом случае, предлагаю не перекидываться предположениями , а взять и проверить. Вроде это достаточно легко делается .

[@dkoldyaev]

Чертовски интересно послушать про асинхронное джанго и преимущества/недостатки по сравнению со сторонними приложениями типа celery. Лично я пока не вижу для себя никаких преимуществ, а только кучу геморроя, но я довольно поверхностно знаю питон

[@ПавелВеткин-о6щ]

На моей работе все наоборот: я пишу оптимизированные запросы на языке RAW SQL, без использования сереализаторов Django. Мне так даже удобнее, но проверяющие специалисты возмущаются и требуют, чтобы я переписал код на ORM и сереализаторов Django, потому что так код будет выглядеть красивее. Возможно, теперь, с нагрузочными тестами, я смогу доказать им, что они ошибаются, используя цифры. Потому что какой смысл тратить больше время на написание orm, который будет менее работать

[@roman1961]

т.е. при миграции модели, нужно править все сырые запросы по моделе?) поэтому коллеги и требуют орм)

[@SeniorPomidorDeveloper]

Что я натворил...

[@Egorius96]

Не, лучше пили видосы по джанге и оптимизации производительности джанги, ускорение джанги и тд, это очень актуально. Желательно сделать новый курс по асинхронной джанге с каким нибудь мощным проектом

[@ELECTROZ0R]

Но ты не учел что в варианте django мы на каждый запрос еще обрабатываем middleware, который за собой на каждый запрос обрабатывает параллельно всю цепочку middleware. А что если вокруг fastapi обернуть эти же процессы middleware (опять же если они необходимы). было бы интересно проверить или выпилить какие-то middleware на стороне django, что бы это было честно. С уважением Динар)

[@SeniorPomidorDeveloper]

Привет, Динар! Я конечно знаю про middleware . Но в этом и была идея , протестовать фреймворки в таком виде, в каком они изначально. Ничего не добавляя и не удаляя. Но для эксперимента конечно надо сделать, проверить какой из них в большей степени замедляет

[@ELECTROZ0R]

@@SeniorPomidorDeveloper Крутые выпуски! И главное полезные. Продолжай в том же духе)

[@pretcb]

Спасибо

[@nickolayvan]

Спасибо большое! А вы персональные курсы даёте?

[@SeniorPomidorDeveloper]

Вот сейчас один курс разрабатываем . На канале будет анонс через пару месяцев

[@romantretyakov6243]

Отличное видео и интересная тема, хотелось бы продолжения. И хотел бы спросить твое мнение поводу django ninja, может ли этот фреймворк являться альтернативой fast api или это своего рода франкенштейн? Как бы он себя показал в подобных тестах, так же как fast api или хуже?

[@SeniorPomidorDeveloper]

Вот надо протестировать! Следующее видео могу с ним сделать

[@romantretyakov6243]

@@SeniorPomidorDeveloper Было бы здорово. Давно слышал о ninja, но не сталкивался, а сейчас смотрю конференцию по django 2024 и там пара спикеров на нем пишут

[@aleksandr3963]

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

[@ВолодяВолодя-ж7д]

Для небольшого интернет магазина/офис солюшена или мвп джанго хорошо подоходит. В большинстве случаев, когда проект +- серьезный рассчитан на среднюю хотя бы нагрузку (100+пользователей) джанго будет проседать, а платить двойные-тройные суммы за доп.интсансы зачем? Да и что из удобства? Админка и генерики встроеные+ мидлтвари, ну оно удобно для совсем тривиальных задач. В большинстве случаев клиенту не хватает админки джанги и просит ее расширять, а это больно, постоянно приходится что-то свое изобретать поверх дженериков джанги либо их переписывать под себя + паттерн актив рекорд, никакую чистую архитектуру нормального не применишь из-за кучи "удобств" встроенных механизмов работы джанго, иными словами большая зависимость от фреймворка и часто это играет в ущерб удобству программисту + более затратно

[@SeniorPomidorDeveloper]

Мне кажется что главный плюс Джанги это ORM, который по функционалу чуть ли не больше чем весь остальной фреймворк. Ну и второе очень важное, куча пакетов, которые можно с Джанго использовать. На любую задачу уже есть готовое решение. Иначе все время уйдет на программирование велосипедов, а бизнес этого не любит. Админка Джанго - вообще барахло, я считаю что от нее лучше сразу избавляться. А способы оптимизации по сути те же что и в других фреймворках. Кеширование, воркеры и тд. А платить двойные-тройные суммы за доп.интсансы , на мой взгляд ничего плохого. Дешевле чем платить двойные-тройные суммы нанимая много разработчиков.

[@ВолодяВолодя-ж7д]

@@SeniorPomidorDeveloper проблема орм-а что он основан на актив рекорде, что создает доп нагрузку для программиста и в целом на поддержку проекта(привет паттерн репозиторий) + нет асинк коннекторов к базе т.е асинк эвейт что сейчас есть по сути бесполезен почти во всех случаях, да для того же фласка и фастапи точно так же есть куча библиотек, скл алхимия не чем не хуже джанговской(по мне так там даже шире функционал), а в некоторых кейсах даже думаю лучше т.к есть четкая модель коммита и того же flush-а. Работал на продукте в месяц на инфру(авс микросервисы) уходило 25к$, узким горлышком была производительность джанги, переписали сервисы на фастапи и сэкономил 7к$, не нанимая никаких новых программистов + получилась чистая архитектура, что гораздо удобнее и гибче нежели типичная джанговская мвс P.s продакшн развертывание фастапи - Guinicorn и воркеры ювикорн, так и в самой документации фастапи написано p.s.s: хотелось бы увидеть тесты на 100/1000/10000 пользователей условно))

[@SeniorPomidorDeveloper]

Ну само собой, делать микросервисы на Джанго это не лучший вариант. Хотя я с трудом представляю как переход на другой фреймворк мог снизить затраты с 25к$ до 7к$. Там явно что-то еще поменяли. Про прошакшн развертывание fast API , идея хорошая. Конечно тесты на коленке, на своем ноуте, это все очень приблизительно. И нагрузка должна в идеале быть более разнообразной. Но 100 клиентов с такой интенсивностью вроде хватило чтобы мой комп нагрузить. Можно проверить, но там у меня уже сокеты в ОС кончаются , ошибки такие падают . Наверное уже другие инструменты нужны и не все на одном компе делать

[@ВолодяВолодя-ж7д]

@@SeniorPomidorDeveloper не, с 25к до 7 это сильно слишком, имел в виду 25-7) 7к экономии в месяц

[@zikden847]

Спасибо большое за видео. Было бы интересно посмотреть похожее тестеравние используя Django Ninja. Автор Фреймворка общает производительность в 3 раза быстрее чем DRF. В теории будет такой же результат как и на FastApi.

[@SeniorPomidorDeveloper]

Да, хорошая идея для следующего видео!

[@madex4336]

потому что джанго говно и для асинков форк челы качают )

[@whiterabbit6211]

1.47 это не полтора минуты ))

[@SeniorPomidorDeveloper]

Блин... )

[@npc-r390]

С await gather интересный вариант, но методы не надо создавать внутри других методов, а их следовало объявить за пределами вьюхи. Это и могло замедлить время

[@SeniorPomidorDeveloper]

Сейчас проверил. Нет. Это не влияет. Разница в десятые процента.

[@The_Establishment]

сделай видео про асинхронные функции

[@koshakpoc2876]

Я всегда думал что fastapi конкурент фласку, для написания микросервисов, а если делать монолит, то инструменты из капота джанги очень даже пригодятся, и они удобные

[@SeniorPomidorDeveloper]

Ну это само собой. Просто хотелось как раз и потестить оверхед фреймворков в чистом виде

[@koshakpoc2876]

@@SeniorPomidorDeveloper да я понял вашу задумку, у вас как всегда топ контент, я просто не очень понимаю в принципе сравнение джанго и фастапи, думал они используются для разных целей

[@SeniorPomidorDeveloper]

Не совсем так. Если мыслить чуть шире, то и монолит и микросервисы ведь используются для одних и тех же целей ) А вот из чего создавать компоненты бекенда веб-приложения, это вопрос спорный. Я бы даже сказал что монолит в чистом виде, как и микросервисы в чистом виде, это вещи довольно дискомфортные для разработки. Для среднего бизнеса, обычно есть приложение и у него несколько сервисов, не один но и не 20. На чем их писать, тут как раз и приходится делать выбор, и скорость ответа фреймворка, это то, что могло бы на этот выбор повлиять.

[@koshakpoc2876]

@@SeniorPomidorDeveloper понял, спасибо

[@МаксимНовиков-ь4ц]

Расскажи отдельно про ассинхронку плиз.

[@СтаниславРассказов-ы4м]

Спасибо за видео. В конце отсылка к недавно разгоревшемуся холивару "CleanCode VS FastCode"?

[@SeniorPomidorDeveloper]

Или к давно разгоревшемуся )

[@dmitriiovsiannikov9605]

Так а запросы в бд синхронные же? То есть кажется толькл в 5 django был добавлен pcycopg3, который и сможет позволить делать асинхронные запросы. В данном этапе получается запросы в бд не делаютсямконкуретно

[@SeniorPomidorDeveloper]

Так я asyncpg использовал, он как раз асинхронный

[@andrewkuzmin4400]

На самом деле сравнивать время ответа конечно можно, но как по мне, куда важнее смотреть на число успешных транзакций. Какой смысл во времени ответа, если количество успешных транзакций(к примеру) будет меньше? Т.е. по факту сервис конечно будет отвечать быстро, но ответ будет, например, будет либо ошибочный, либо не содержащий данные. И да, если так смотреть, то рулит 1ый вариант в случае с Django (gunicorn c 4 воркерами и 2 тредами) и последний с FastAPI.

[@SeniorPomidorDeveloper]

Тут число успешных транзакций 99.6% - 99.8% , я эти десятые процента особо не учитываю. Все таки тесты довольно грубые, на ноуте рабочем. Много погрешностей в этих расчетах, в любом случае.

[@ПавелВеткин-о6щ]

Я бы вообще хотел перейти с Django на Fastapi, но на нем вакансий значительно меньше. Ставь лайк если тоже хочешь сменить работу с Django на fastapi

[@vasisafronov]

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

[@nucluster]

​@@vasisafronovа можно пояснить в чем именно плохо?

[@Jason-lk6gb]

@@vasisafronov а почему вторичны? И что на первом месте?

[@agentdaun5699]

@@Jason-lk6gb На первом месте быть программистом, а не заложником фреймворка/языка(если говорим про людей хоть с каким-то опытом) джанги фастапи лайтстары блэкшипи это обычно 0.1% работы

[@vasisafronov]

@@nucluster отсутствие квалифицированных специалистов, которые могут в процессы, понимают какие проблемы бизнеса они помогают решать и почему именно так, умеют написать поддерживаемый понятный код, который решает именно обозначенную проблему согласно бизнес логики с первого раза. По моим наблюдениям самая большая проблема это что программисты не запускают написанный ими код перед сдачей PRа и не проверяют выполняет ли он поставленную задачу. Если разраб в конце разработки хотя бы запускает постман и проверяет все кейсы согласно описанной бизнес логике к задаче, то это уже повышает его ценность в двое. Если он еще документацию напишет к методам и тесты, то это вообще сказка какая-то. Если разраб пишет только тот код, который нужен для решения поставленной задачи, не тащит лишних зависимостей, не усложняет ничего, а просто решает проблему, то я готов с ним работать. Но таких нет...

[@inftech8976]

Мне кажется, что все таки неравные условия, вам надо было бы код фастапи разложить функционал по папкам также как и django, вот и тогда сравнивать по скорости

[@SeniorPomidorDeveloper]

Да не в этом дело. Импорты это копейки. Дело в Джанго мидлваре

[@inftech8976]

@@SeniorPomidorDeveloper Мой кент знакомый, любил всякие костыли, и на работе посоветовал попробовать django на интерпретаторе pypy, и он сказал, что он обгонит фастапи, а фастапи не может перейти на pypy, из за pydantic, ну в принципе логично

[@inftech8976]

@@SeniorPomidorDeveloper может попробуете как нибудь

[@fdrov]

Видос огонь🔥 Спасибо! Кстати, насколько корректно джанга 4воркера2треда сравнивать с фастапи 8 воркеров

[@SeniorPomidorDeveloper]

Да фиг знает, просто с разными вариантами эксперементировал)

[@АлександрНекрасов-г9в]

Кажется, что не хватило тестов: 1) uvicorn vs gunicorn + синхронная джанга ( сравнение происзводительности WSGI и ASGI серверов в случае с джанго) 2) SQLAlchemy vs DjagoORM 3) лучший ORM(из пункта №2) vs RAW SQL 4) Деградация скорости ответа в зависимости от количества клиентов P.S. ждем видос по сравнению способов кэширования P.S.S Интересно глянуть на сравнение производительности FastAPI vs Litestar. Если верить бэнчмарку из официальной документации последнего, то он значительно быстрее работает с json\файлами

[@SeniorPomidorDeveloper]

Согласен! Я еще не все тесты включил в видео. И так 35 минут это огромная длительность. Но SQLAlchemy vs DjagoORM наверное стоило сделать! Это да. Сейчас сделал тест FastAPI + SQLAlchemy и получилось в два раза дольше чем FastAPI + SQL. А для Джанги отказ от ORM дает только 30% прироста. Вот как-то так...

[@faralostik]

было бы круто еще фласк добавить для сравнения

[@commonbro1871]

Можно ролик про то, как правильно писать views, котороые могут создавать сложные объекты, когда один объект зависит от разных сущьностей, просто как новичку не совсем понятно, как писать такую логику на django?

[@SeniorPomidorDeveloper]

А зачем писать логику , где один объект зависит от разных сущностей ? )

[@commonbro1871]

Допустим бывают случаи, когда мы с помощью переопределения метода perform_create() вытаскиваем user из запроса и связываем его с нашим объектом, а бывают же ситуации, когда помимо user необходимо наш объект связать с ещё какими-то сущностями, где правильно это писать ?

[@SeniorPomidorDeveloper]

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

[@fokusname2600]

1.5 секунды это много, а если еще добавить загрузку фроонтеда. 3секунды допустимо если дольше, то клиента будет вызвывать отвращение

[@ЛеонидЛеонидов-ь9в]

Redis или другое кэширование сведет все это дело к около мгновенной загрузке у клиента

[@fokusname2600]

@@ЛеонидЛеонидов-ь9в уф

[@SeniorPomidorDeveloper]

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

[@bernardsoul8936]

14:40 лучше добавлять в кортежи, они меньше занимают памяти и быстрее списков

[@SeniorPomidorDeveloper]

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

[@bernardsoul8936]

@@SeniorPomidorDeveloper я тестил списки и кортежи не в веб приложении, а просто в запускал цикл с миллионом итераций. Сейчас почитал об этом подробнее и потестил еще раз. Размеры кортежа из 1млн элементов действительно меньше, а со скоростью есть ньюанс. Зависит от того как записывать

[@SeniorPomidorDeveloper]

@@bernardsoul8936 Зависит от контекста, где-то в Джанго эта разница потеряется. Обычно мы не передаем на фронтенд 1мил объектов. Даже 10тыс не передаем. А вот в биг дата да, очень даже актуально.

[@bernardsoul8936]

@@SeniorPomidorDeveloper согласен)

[@МагомедИбрагимов-с8ъ]

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

[@SeniorPomidorDeveloper]

Здравствуйте! У меня была книга Алгоритмы. Теория и практическое применение. | Стивенс Род Но сегодня я бы использовал чат gpt для изучения, просто быстрее и меньше усилий . А если совсем по серьезному то лучше даже с преподом их изучать, чем с книгой .

[@restovrator1128]

Сделайте пожалуйста видео по ассинхронке