Я поднял свой уровень бэкенда за 35 минут 😁 очень интересна тема оптимизации и нагрузочного тестирования, хочу еще!)
@AlekseiMishinАй бұрын
Тема производительности супер интересна, пили ещё плз)
@MynameLotus-y4bАй бұрын
Благодарю за ваши видео! ждем курс по async и Fastapi
@lightgod4669Ай бұрын
супер)думал попью кофе,посмотрю минут 5-10 и пойду кодить,по итогу все 35 мин просидел)контент пушка
@SeniorPomidorDeveloperАй бұрын
Спасибо!
@oldcodersАй бұрын
Очень познавательно! Спасибо!
@SeniorPomidorDeveloperАй бұрын
Спасибо Деду!
@ElenaVi93Ай бұрын
Благодарю за ваши видео! Очень полезно! Интересно все!!! Выпускайте больше и спасибо, что с уважением относитесь к чайникам и объясняете очень добротно и подробно!
@sinya_devАй бұрын
Был очень рад увидеть сравнение, видно, что вложено немало сил, огромное спасибо за видос! Лично я пишу на FastAPI, предпочел его из-за быстродействия на слабеньких железках. Да и мне как-то проще писать на нем)
@user-ku8cu5kv2qАй бұрын
Пересмотрел все ваши курсы залпом. Узнал очень много мелких тонкостей. Спасибо большое. Было бы очень посмотреть курсы по асинхронности и по FastAPI. Огромное спасибо за такой хороший материал и подачу!
@SeniorPomidorDeveloperАй бұрын
Спасибо за просмотры!
@Rasty_BossАй бұрын
yes need course about FastAPI
@sachivkinАй бұрын
Очень крутое, интересное и полезное видео, спасибо! В целом темы по Django, Fast API и асинхронному Python интересны! :)
@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 в том числе, конечно нужно. Я только за.
@user-no4jf5uj9qАй бұрын
ДжангА, как и вордпресс будут жить "вечно", собствено как и языки на которых они написаны. Кстати а чатгпт может написать новый ЯП? Что интересно он возьмет за основу?
@SeniorPomidorDeveloperАй бұрын
Не думаю что Гат ГПТ может написать новый ЯП. Да и если бы мог, догадываюсь что это был бы за ЯП, мне уже плакать хочется)
@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 все-таки. Про драйвера ясно, спасибо.
@davidsaidov8308Ай бұрын
Было очень интересно, спасибо!
@pytag6548Ай бұрын
Ждем курсы по Fastapi, asyncio. Сравнение Fastapi, Esmerald, Starlette, Litestar (нагрузочное тестирование). Спасибо!
@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?
@user-ns2cf8zu8rАй бұрын
Согласен, особенно посмеялся над выводами. Видео ни о чем В наши дни любой кто смог написать 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 и прочее, иметь ввиду что одни запросы запускаются чаще других. Конечно на "реальном железе" надо это делать. И еще много всего. Это такая скорее обзорная экскурсия.
@goblingo9042Ай бұрын
Как всегда лайк - сделано очень продуманно и качественно! Объясняете в меру и не перегружаете инфой. Спасибо Вам за ваш труд! Сделайте еще видео про генерацию фейковых данных для нагрузочного тестирования, пожалуйста.
@goro2120Ай бұрын
Мне как человеку который пишет на спринге было очень интересно послушать,Круто!
@SeniorPomidorDeveloperАй бұрын
Класс! Спринг - сила!
@forest_1771Ай бұрын
Действительно отличное видео! Я думаю многим интересен такой формат, хотелось бы больше подобных видео!
@bernardsoul8936Ай бұрын
Видео классное и интересное! Лайк! Голосую за курс по FastAPI
@Rulezzz3Ай бұрын
Тема тестирования очень интересна. Мало информации по нему в ютубе. Снимай видео. Очень приятно тебя смотреть
@SeniorPomidorDeveloperАй бұрын
Спасибо!
@user-vl1fx6ef1qАй бұрын
Спасибо за качественный контент. Я поднял свои знание. Продолжай в том же духе
@kopo4yh469Ай бұрын
Да это не помидор, это Помидоорищеее🎉 лютая годнота
@SeniorPomidorDeveloperАй бұрын
🤣
@constantinemalykhinАй бұрын
Очень крутое видео! Спасибо! Да, хотелось бы еще в таком роде
@VictorPriymaАй бұрын
Огромная благодарность за проделанную работу!!!
@romansozinovАй бұрын
Лайк за исследование!
@npc-r390Ай бұрын
Джанго медленнее, но все запросы она прогоняет через middleware сессий, аутентификацией, csrf и тд. Если в фастапи делать полноценный сайт со всеми этими функциями, то мб +/- одинаково по скорости будет. Если делать внутренний микросервис, тогда норм
@valentynmalyiАй бұрын
да нужно выкинуть все что не используеться INSTALLED_APPS = ['myapp'] MIDDLEWARE = []
@SeniorPomidorDeveloperАй бұрын
Согласен
@MrEligosАй бұрын
Дак в чем проблема сделать и проверить, не чего не будет +/-, откуда такие мысли. Бред какой
@SeniorPomidorDeveloperАй бұрын
Что опять я должен проверять??
@SeniorPomidorDeveloperАй бұрын
Ладно. Проверил. Действительно, без middleware разница не большая, может 15% или даже в пределах погрешности. Если на сервере проверят то можно было бы точнее сказать. Но да, уже видно что middleware не особо влияют
@opium3156Ай бұрын
больше видео про асинхронность !
@ZZZMerkАй бұрын
Спасибо за видео, очень зашло) Касательно асинк темы - однозначно хочется услышать ваше понимание, сравнить со своим после прочтения книжки Фаулера :)
@SeniorPomidorDeveloperАй бұрын
Рад что видео зашло . Боюсь что после книжки Фаулера мне не много что будет добавить) Но как-нибудь надо сделать, тема конечно интересная
@xizltАй бұрын
Спасибо. Вот прям шикарные видео и идеи для них
@user-ff4bg5go9fАй бұрын
Спасибо!!!
@bvkipossАй бұрын
уфф какая же имба под вечер
@SpautАй бұрын
Я ждал еще вариант сравнения c fastapi + sqlalchemy
@SeniorPomidorDeveloperАй бұрын
Да, я уже понял что надо было! ) Сейчас сделал тест FastAPI + SQLAlchemy и получилось в два раза дольше чем FastAPI + SQL.
@madex4336Ай бұрын
@@SeniorPomidorDeveloper у алхимии два апи и асинронное значительно быстрее и даже при это ПЛЕВАААТЬ же)) другие условия будут определятЬ. кверибилды юзать в проекте или орм.
@user-wl7qy6xl6sАй бұрын
Вау круто! Подписка лайк. Ничего не знаю в питоне, от слова 0. Но тут все понял 😂 Буду учить
@deffunction7657Ай бұрын
Такой Вы хороший человек, спасибо
@dunhillkekov3383Ай бұрын
Спасибо за контент! очень интересно
@KUBD99612 күн бұрын
Спасибо за ролик! Очень информативно. Можно тесты разных базы данных?
@SeniorPomidorDeveloper12 күн бұрын
Пожалуйста. Пока не планировал , да и тут не получится ограничиться запросами на чтение. Надо и запись тестировать и кеширование на уровне базы и запросы с фильтром. индексы , короче большая тема.
@KUBD99611 күн бұрын
@@SeniorPomidorDeveloper окей
@user-kn5ip9lr6rАй бұрын
Спасибо большое, ценные знания. У вас очень эксклюзивный контент, которые не встретишь нигде. В основном все друг друга повторяют (по крайней мере, в Ютубе). Что касается темы видео, был удивлен, насколько сильно использование ORM снижает время ответа от сервера. Я так понимаю, Django требуется время чтобы перевести queryset-выражения на sql-выражения, отсюда и разница во времени. Ну а скорость ответа от сервера роли не играет. Даже если страница будет загружаться на 1-2 секунды дольше (а это очень много), большинству пользователей плевать - они даже не заметят. Так что лично я думаю, что удобство и простота разработки важнее для бизнеса, чем оптимизация кода. И еще где-то читал, что современные приложения (не только веб, а и вообще) оценивают с точки зрения потребления энергии аккумулятора, а не количества времени работы процессора, а это не всегда одно и то же. Пожалуйста, расскажите подробнее про асинхронность в Django, когда стоит и есть ли вообще смысл использовать sync_to_async и т.д. Успехов в развитии канала 👍
@SeniorPomidorDeveloperАй бұрын
Спасибо большое за такой хороший отзыв! Да, в таком простейшем сравнении, у меня получились результаты что на 30% или на 0,06 миллисекунд orm увеличивает время ответа. Но надо понимать что реальные запросы в базу как правило сложнее и тяжелее. Если сам запрос выполняется пол секунды, то оверхед, которые накладывает orm уже будет относительно меньше. То есть будет 0,5 сек на запрос плюс те же 0,06 на прослойку orm. Это уже не на 30% увеличение времени , а совсем на малую долю. Так что да. Это не повод отказываться от ORM, лучше уж тогда от SQL отказываться, тогда реально можно скорость поднять.
@sleepmode7592Ай бұрын
Максимально интересно и познавательно, снимай, пожалуйста, еще такого плана видео. Хотелось бы увидеть сравнение python с golang насколько велика разница между ними под нагрузкой. Спасибо!)
@SeniorPomidorDeveloperАй бұрын
Да да! Ты прям угадал тему для следующего видео )
@ragimov700Ай бұрын
Это было реально интересно, спасибо! Единственное, хотелось бы увидеть скорость FastAPI без оптимизаций, но это уже придирки. Видео получилось очень полезным и наглядным. Плюсую к курсу по FastAPI и жду продолжения роликов про производительность!
@SeniorPomidorDeveloperАй бұрын
Да там и не было особо оптимизаций, просто минимальное приложение. Как и на Джанге. Сейчас сделал тест его же на FastAPI + SQLAlchemy и получилось в два раза дольше чем FastAPI + SQL.
@antont5229Ай бұрын
@@SeniorPomidorDeveloper сейчас делаю проект FastAPI + MongoDB с использованием Beanie ORM, интересно будет потестить свой проект, какой результат выдаст ))
@gnjjnhfcАй бұрын
Классное видео! Было бы интересно увидеть теиу на продакшн сервере как тонко настроить uvucorn и тд для fastapi. С тестированием
@user-gn6oh4qw3gАй бұрын
Очень интересное видео!
@11kapitan1Ай бұрын
Супер интересно , тоже наверное протестирую
@RomaCostinАй бұрын
ахуенно. давай курс по FastAPI
@sleepmode7592Ай бұрын
Было б интересно еще глянуть сравнения не только фреймворков или языков, но и разных баз данных, к примеру postgres, mysql, sqlite, mongo, clickhouse
@eugenekolomiets7608Ай бұрын
Спасибо за сравнение!
@user-ik4ky1yw2eАй бұрын
Спасибо за видео!
@smashing_timesАй бұрын
крутое видео! спасибо!
@stiker7778Ай бұрын
Можно нагрузку питонячью очень удобно грузить через Locast, тоже удобная библа для таких тестов
@user-xl1zq2ic5fАй бұрын
Полезно! Спасибо
@JastcherАй бұрын
Пасиб за видео! Про асинхронность в джанге интересно) Что реально применимо, а что не очень. И интересно сравнение asyncpg vs psycopg2/3
@SeniorPomidorDeveloperАй бұрын
Да все применимо , было бы желание ) asyncpg vs psycopg2 - там в видео было. По сути все асинхронное ORM идет по asyncpg.
@antonromanov4554Ай бұрын
оч интересно , спасибо
@mellonface5280Ай бұрын
Асинхронные сервера больше подходят для того чтобы параллельно обрабатывать много запросов. Думаю асинхронный сервер не сильно ухудшится в производительности даже если клиентов будеь в 10-20 раз больше. А вот на счет синхронных серверов я не уверен, думаю они быстро начнут деградировать при таком росте количества одновременных запросов.
@SeniorPomidorDeveloperАй бұрын
У меня и тот и другой деградируют если я скажем в два раза увеличиваю нагрузку. Хотя возможно тут влияет что я тестирую на домашнем ноуте. В следующий раз на мощном сервере попробую
@Айти_братАй бұрын
Привет Сеньор помидор=). уважаю тебя, давно смотрю. от тебя заразился так же любовью к макбук и вот купил такой же на 16гБ поставил плагин как у тебя чтобы в трее загрузку по цп и озу видно было) ну а в целом конечно приятно тебя смотреть и перенимать опыт по джанго-фастапи
@SeniorPomidorDeveloperАй бұрын
Привет! Спасибо за отзыв! Мне пора уже заделаться амбасадором Мака. Почему они мне не платят😆
@user-wd4hw6dy1iАй бұрын
Как по мне не очень корректно сравнивать такое приложение. В продакшене всегда будут более сложные запросы к базе, что скорее всего даст совершенно другой результат между синк и асинк джангой, соответственно и разницу между фаст апи и джанго. Было бы интересно посмотреть на что-то похожее на продакшен где будут запросы потяжелее, запросов побольше, без чистого sql. А затем ещё сравнить обмазав кешем. Между 0,3 и 0,12 пользователь конечно не заметит скорее всего, но вот поднимать больше подов уже критичнее.
@agentdaun5699Ай бұрын
" но вот поднимать больше подов уже критичнее." - почему? Обычно наоборот скейлят не воркерами, а подами. Для более адекватной утилизации времени CPU
@SeniorPomidorDeveloperАй бұрын
Да где же мне взять "что-то похожее на продакшен". Я бы с удовольствием на основе этого видео сделал. Но тут была цель другая. Протестировать сами фреймворки без всякой внутренней логики, чтобы понять какой они оверхед накладывают. Как они работают в чистом видео. А потом уже адаптировать под свои нужды сможет каждый, но у каждого свои условия и свои запросы.
@andyabsent4648Ай бұрын
Супер круто. Спасибо
@vegzuzvegzuz2866Ай бұрын
Отличное видео!
@runderoy6650Ай бұрын
Спасибо за твой труд! Если есть мысли о курсе по FastAPI, уверен многие его очень оценят! Хотелось бы услышать твоё мнение о том, как и в каких ситуациях следует разрабатывать бэкенд на том или ином фреймворке, и в целом разбор преимуществ/недостатков каждого из них :)
@SeniorPomidorDeveloperАй бұрын
Хороший вопрос. Не знаю получилось ли бы дать какие-то общие рекомендации, надо подумать. Часто бывает что бизнес сам не знает какое должно получится приложение, какая и какого типа будет нагрузка и тд. И фреймворк часто выбирается рандомно или по вкусам разработчика.
@the_codestАй бұрын
Привет, senior! 1) Спасибо за видео! Очень интересно и полезно! 2) Всё предложенное тобой к тематике следующих видосов - конечно, интересно. Спасибо, что вообще находишь время для таких исследований и делишься ими! Ты крутой! 3) Слышал ли ты что-нибудь о фреймворке LiteStar? Это активно развивающаяся альтернатива FastAPI, но он совсем не раскручен, вакансий не видел по нему. Если "трогал" или видел что-то, очень интересно твое мнение. Ещё раз спасибо! Всем добра!
@SeniorPomidorDeveloperАй бұрын
Спасибо за такой отзыв! Сам LiteStar не пробовал. Тут уже несколько раз его советовали. Можно попробовать тоже. Вообще сейчас появляется много новых фреймворков. Вот на js, каждый год появляется какой-то модный фреймворк, все начинают свой код переписывать на него, потом проходит год и ситуация повторяется. У нас вот нет такой возможности. Бекенд вообще очень консервативен. 76% сайтов написаны на php, на втором месте стоит C# , куда там до модных фреймворков
@user-qh2em5cb2iАй бұрын
Как вам проводить нагрузочное тестирование между Django Ninja и DRF?
@romantretyakov6243Ай бұрын
Отличное видео и интересная тема, хотелось бы продолжения. И хотел бы спросить твое мнение поводу django ninja, может ли этот фреймворк являться альтернативой fast api или это своего рода франкенштейн? Как бы он себя показал в подобных тестах, так же как fast api или хуже?
@SeniorPomidorDeveloperАй бұрын
Вот надо протестировать! Следующее видео могу с ним сделать
@romantretyakov6243Ай бұрын
@@SeniorPomidorDeveloper Было бы здорово. Давно слышал о ninja, но не сталкивался, а сейчас смотрю конференцию по django 2024 и там пара спикеров на нем пишут
@understandwhatАй бұрын
спасибо большое!
@mrfreeman2536Ай бұрын
пишу! асинхронные вещи, интересно!)
@the_huge_knightАй бұрын
Интересные варианты работы одного и того же приложения. Вариант с FastAPI также надо было сделать с ORM и сериализацией. И тогда сравнить синхронный Django с асинхронным FastAPI. А то получилось, что 5 вариантов на Django и всего 1 вариант на FastAPI.
@SeniorPomidorDeveloperАй бұрын
Потестировал сейчас FastAPI + SQLAlchemy , получилось в два раза дольше чем на сыром SQL. А в Джанго отказ от ORM дает прирост всего на 30%.
@SeniorPomidorDeveloperАй бұрын
Сериализаторы вроде нет разницы особо со словарями. Разница в пределах погрешности.
@MrNagiosАй бұрын
производительность - это супер интересная тема, я на ней завернут
@Katar1xАй бұрын
давай про кеширование)
@nickolayvanАй бұрын
Спасибо большое! А вы персональные курсы даёте?
@SeniorPomidorDeveloperАй бұрын
Вот сейчас один курс разрабатываем . На канале будет анонс через пару месяцев
@Play-fs9gvАй бұрын
А мне подумалось что более важной цифрой будет как раз следующая строчка "Transaction rate". В том смысле что для общей производительности более важно не время ответа на один запрос - ну действительно открылась страница на 0.05 сек медленнее ну и что - а важнее сколько клиентов сумел обслужить сервер. Да, каждому ответил чуть медленнее, но зато в полтора раза больше клиентов сумели открыть страницу. В принципе эти цифры от теста к тесту так же меняются - место с общем рейтинге не изменится, но увеличение там совсем не такое драматическое. По одному показателю вроде быстрее в три раза, а по другому - было 375 а стало 500 - всего в полтора раза больше транзакций обслужено.
@SeniorPomidorDeveloperАй бұрын
Согласен. Для нагрузочного тестирования эта цифра более важная. Мне уже пишут об этом несколько человек. Для нас разработчиков, более привычная цифра это время ответа от сервера. Но надо и туда и туда смотреть, это да
@MER1D1ANАй бұрын
Хотел бы ещё посмотреть, во-первых кэширование. И фастаип
@user-ng6nx1uo5uАй бұрын
Спасибо за видео! Если убрать фразу про лаконичность кода (хотя остался вопрос по поводу производительности fastapi не на чистом sql, а с использованием алхимии), то видео выглядит как прогрев перед курсом по fastapi)))
@SeniorPomidorDeveloperАй бұрын
Уже понял что надо было сделать этот тест, все про него спрашивают) Сейчас сделал тест FastAPI + SQLAlchemy и получилось в два раза дольше чем FastAPI + SQL. Вот как-то так. Курс по FastAPI не готовится, но кое-что другое будет)
@r.chitectorАй бұрын
Спасибо за такое сравнение! Очень было познавательно! Но не хватило сравнения "дефолтной" конструкции Django и "дефолтной" конструкции Fastapi (если конечно у fastapi есть какой-то дефолтный подход к построению запросов и вьюшек аналогично джанге, я не знаток фастапи)
@SeniorPomidorDeveloperАй бұрын
Думаю что такой "дефолтной конструкции" подобно той , которая в Джанго, в FastAPI нету.
@pretcbАй бұрын
Спасибо
@RomaCostin5 күн бұрын
Ответь пажалуйста, Можно ли на Django/DRF делать проекты с микросервесной архитектурой и популярно ли такое решение в реальной разработке ?
@SeniorPomidorDeveloper5 күн бұрын
Делать можно. Но наверное такое не популярно. Хотя я не вижу больших причин почему нет
@user-xj9nv6vi1t17 күн бұрын
Здравствуйте , хотел бы у вас поинтересоваться , вы изучали алгоритмы? если да то можете посоветовать литературу или курсы какие нибудь?
@SeniorPomidorDeveloper17 күн бұрын
Здравствуйте! У меня была книга Алгоритмы. Теория и практическое применение. | Стивенс Род Но сегодня я бы использовал чат gpt для изучения, просто быстрее и меньше усилий . А если совсем по серьезному то лучше даже с преподом их изучать, чем с книгой .
@user-eo3dp5uj6sАй бұрын
Расскажи отдельно про ассинхронку плиз.
@liopox_Ай бұрын
24:25 Да, асинхронность помогает когда эти запросы работают не мгновенно, например, если бд развернуто на другом сервере и есть хоть какой-то пинг.
@liopox_Ай бұрын
Более того, на сколько я понял, так как все запущено на одном компьютере, база замедляет работу сервера и делает асинхронный подход полностью бесполезным.
@SeniorPomidorDeveloperАй бұрын
База замедляет асинхронный код в той же мере что и синхронный. Разве нет? В любом случае, предлагаю не перекидываться предположениями , а взять и проверить. Вроде это достаточно легко делается .
@markjulian2912Ай бұрын
А можно гайд по удаленному хранению статики и медиа, то есть хороший такой гайд по django-storages. В интернете оч мало информации по тому как сделать удаленное хранилище и передавать файлы статики например по sftp. Залайкайте пожалуйста, на ютубе не нашел такого контента:(
@SeniorPomidorDeveloperАй бұрын
Хорошая тема. Довольно непростая . Хотя на первый взгляд кажется что ничего сложного. Может как-нибудь доберусь , сделаю
@stiker7778Ай бұрын
Хочется увидеть разные методы кэширования !
@marvillbarrow3375Ай бұрын
Я один обратил внимание на то, что падает Availability при использовании gunicorn? И повышается количество транзакций.
@SeniorPomidorDeveloperАй бұрын
Доступность 99.6% - 99.8% , я эти десятые процента особо не учитываю. Все таки тесты довольно грубые, на домашнем компе. Был бы сервер, наверное имело бы смысл на них смотреть. А количество транзакций повышается пропорционально среднему времени запроса. Это по сути говорит об одном и том же.
@dkoldyaevАй бұрын
Чертовски интересно послушать про асинхронное джанго и преимущества/недостатки по сравнению со сторонними приложениями типа celery. Лично я пока не вижу для себя никаких преимуществ, а только кучу геморроя, но я довольно поверхностно знаю питон
@zikden847Ай бұрын
Спасибо большое за видео. Было бы интересно посмотреть похожее тестеравние используя Django Ninja. Автор Фреймворка общает производительность в 3 раза быстрее чем DRF. В теории будет такой же результат как и на FastApi.
@SeniorPomidorDeveloperАй бұрын
Да, хорошая идея для следующего видео!
@madex4336Ай бұрын
потому что джанго говно и для асинков форк челы качают )
@dmitriiovsiannikov9605Ай бұрын
Так а запросы в бд синхронные же? То есть кажется толькл в 5 django был добавлен pcycopg3, который и сможет позволить делать асинхронные запросы. В данном этапе получается запросы в бд не делаютсямконкуретно
@SeniorPomidorDeveloperАй бұрын
Так я asyncpg использовал, он как раз асинхронный
@user-bn6rs5ci3bАй бұрын
По поводу того что небыло прироста производительности в ассинхронной джанге даже при одновременном выполнении запросов, думаю дело в том что в принципе нет особого смысла в ассинхронном выполнении запросов к бд когда эти запросы выполняются быстро (до 50мс), питон больше ресурсов тратит на ассинхронное выполнение. А вот если бы запросы были бы более "тяжелыми" то тогда был бы другой результат.
@SeniorPomidorDeveloperАй бұрын
Согласен. В идеале надо на реальном приложении тестить и оптимизировать под свои нужны, там где это имеет смысл.
@ELECTROZ0RАй бұрын
Но ты не учел что в варианте django мы на каждый запрос еще обрабатываем middleware, который за собой на каждый запрос обрабатывает параллельно всю цепочку middleware. А что если вокруг fastapi обернуть эти же процессы middleware (опять же если они необходимы). было бы интересно проверить или выпилить какие-то middleware на стороне django, что бы это было честно. С уважением Динар)
@SeniorPomidorDeveloperАй бұрын
Привет, Динар! Я конечно знаю про middleware . Но в этом и была идея , протестовать фреймворки в таком виде, в каком они изначально. Ничего не добавляя и не удаляя. Но для эксперимента конечно надо сделать, проверить какой из них в большей степени замедляет
@ELECTROZ0RАй бұрын
@@SeniorPomidorDeveloper Крутые выпуски! И главное полезные. Продолжай в том же духе)
@user-qp8of2vk9yАй бұрын
Спасибо за видео. В конце отсылка к недавно разгоревшемуся холивару "CleanCode VS FastCode"?
@SeniorPomidorDeveloperАй бұрын
Или к давно разгоревшемуся )
@whiterabbit6211Ай бұрын
1.47 это не полтора минуты ))
@SeniorPomidorDeveloperАй бұрын
Блин... )
@andrewkuzmin4400Ай бұрын
На самом деле сравнивать время ответа конечно можно, но как по мне, куда важнее смотреть на число успешных транзакций. Какой смысл во времени ответа, если количество успешных транзакций(к примеру) будет меньше? Т.е. по факту сервис конечно будет отвечать быстро, но ответ будет, например, будет либо ошибочный, либо не содержащий данные. И да, если так смотреть, то рулит 1ый вариант в случае с Django (gunicorn c 4 воркерами и 2 тредами) и последний с FastAPI.
@SeniorPomidorDeveloperАй бұрын
Тут число успешных транзакций 99.6% - 99.8% , я эти десятые процента особо не учитываю. Все таки тесты довольно грубые, на ноуте рабочем. Много погрешностей в этих расчетах, в любом случае.
@ibrahimogluАй бұрын
👍
@Egorius96Ай бұрын
Не, лучше пили видосы по джанге и оптимизации производительности джанги, ускорение джанги и тд, это очень актуально. Желательно сделать новый курс по асинхронной джанге с каким нибудь мощным проектом
Да фиг знает, просто с разными вариантами эксперементировал)
@user-ie2rg1in7xАй бұрын
На моей работе все наоборот: я пишу оптимизированные запросы на языке RAW SQL, без использования сереализаторов Django. Мне так даже удобнее, но проверяющие специалисты возмущаются и требуют, чтобы я переписал код на ORM и сереализаторов Django, потому что так код будет выглядеть красивее. Возможно, теперь, с нагрузочными тестами, я смогу доказать им, что они ошибаются, используя цифры. Потому что какой смысл тратить больше время на написание orm, который будет менее работать
@roman1961Ай бұрын
т.е. при миграции модели, нужно править все сырые запросы по моделе?) поэтому коллеги и требуют орм)
@SeniorPomidorDeveloperАй бұрын
Что я натворил...
@user-yl6wt2ki8tАй бұрын
Верхний правый скриншот: все ответы по ~0.01, а один из них аж 6 секунд. Я что-то не понимаю или именно из-за этого долгого ответа средняя 0.30? Мб перепроверить?
@SeniorPomidorDeveloperАй бұрын
Да не. Если там 20.000 запросов , а несколько будет зависать надолго, то все ровно на средний результат это практически не влияет. Там не мало запросов зависает, видимо по тому что ОС перегружена и не хватает чего-то, во что-то упирается . Я перепроверял, разница не большая, два одинаковых теста подряд почти в точности дают одинаковый результат
@user-yl6wt2ki8tАй бұрын
@@SeniorPomidorDeveloper понял. Справедливо. Хотя странно, что почему-то большая часть запросов достаточно быстро выполняется, а единицы так сильно отстают, создавая погоду среднюю
@koshakpoc2876Ай бұрын
Я всегда думал что fastapi конкурент фласку, для написания микросервисов, а если делать монолит, то инструменты из капота джанги очень даже пригодятся, и они удобные
@SeniorPomidorDeveloperАй бұрын
Ну это само собой. Просто хотелось как раз и потестить оверхед фреймворков в чистом виде
@koshakpoc287629 күн бұрын
@@SeniorPomidorDeveloper да я понял вашу задумку, у вас как всегда топ контент, я просто не очень понимаю в принципе сравнение джанго и фастапи, думал они используются для разных целей
@SeniorPomidorDeveloper29 күн бұрын
Не совсем так. Если мыслить чуть шире, то и монолит и микросервисы ведь используются для одних и тех же целей ) А вот из чего создавать компоненты бекенда веб-приложения, это вопрос спорный. Я бы даже сказал что монолит в чистом виде, как и микросервисы в чистом виде, это вещи довольно дискомфортные для разработки. Для среднего бизнеса, обычно есть приложение и у него несколько сервисов, не один но и не 20. На чем их писать, тут как раз и приходится делать выбор, и скорость ответа фреймворка, это то, что могло бы на этот выбор повлиять.
@koshakpoc287629 күн бұрын
@@SeniorPomidorDeveloper понял, спасибо
@aleksandr3963Ай бұрын
Автору спасибо за труды! Да Джанго медленный, но из коробки он содержит в себе много плюшек. В современном мире наверное важнее время и удобство программиста. А производительность железа периодически удваивается.
@user-ch3de2wt5bАй бұрын
Для небольшого интернет магазина/офис солюшена или мвп джанго хорошо подоходит. В большинстве случаев, когда проект +- серьезный рассчитан на среднюю хотя бы нагрузку (100+пользователей) джанго будет проседать, а платить двойные-тройные суммы за доп.интсансы зачем? Да и что из удобства? Админка и генерики встроеные+ мидлтвари, ну оно удобно для совсем тривиальных задач. В большинстве случаев клиенту не хватает админки джанги и просит ее расширять, а это больно, постоянно приходится что-то свое изобретать поверх дженериков джанги либо их переписывать под себя + паттерн актив рекорд, никакую чистую архитектуру нормального не применишь из-за кучи "удобств" встроенных механизмов работы джанго, иными словами большая зависимость от фреймворка и часто это играет в ущерб удобству программисту + более затратно
@SeniorPomidorDeveloperАй бұрын
Мне кажется что главный плюс Джанги это ORM, который по функционалу чуть ли не больше чем весь остальной фреймворк. Ну и второе очень важное, куча пакетов, которые можно с Джанго использовать. На любую задачу уже есть готовое решение. Иначе все время уйдет на программирование велосипедов, а бизнес этого не любит. Админка Джанго - вообще барахло, я считаю что от нее лучше сразу избавляться. А способы оптимизации по сути те же что и в других фреймворках. Кеширование, воркеры и тд. А платить двойные-тройные суммы за доп.интсансы , на мой взгляд ничего плохого. Дешевле чем платить двойные-тройные суммы нанимая много разработчиков.
@user-ch3de2wt5bАй бұрын
@@SeniorPomidorDeveloper проблема орм-а что он основан на актив рекорде, что создает доп нагрузку для программиста и в целом на поддержку проекта(привет паттерн репозиторий) + нет асинк коннекторов к базе т.е асинк эвейт что сейчас есть по сути бесполезен почти во всех случаях, да для того же фласка и фастапи точно так же есть куча библиотек, скл алхимия не чем не хуже джанговской(по мне так там даже шире функционал), а в некоторых кейсах даже думаю лучше т.к есть четкая модель коммита и того же flush-а. Работал на продукте в месяц на инфру(авс микросервисы) уходило 25к$, узким горлышком была производительность джанги, переписали сервисы на фастапи и сэкономил 7к$, не нанимая никаких новых программистов + получилась чистая архитектура, что гораздо удобнее и гибче нежели типичная джанговская мвс P.s продакшн развертывание фастапи - Guinicorn и воркеры ювикорн, так и в самой документации фастапи написано p.s.s: хотелось бы увидеть тесты на 100/1000/10000 пользователей условно))
@SeniorPomidorDeveloperАй бұрын
Ну само собой, делать микросервисы на Джанго это не лучший вариант. Хотя я с трудом представляю как переход на другой фреймворк мог снизить затраты с 25к$ до 7к$. Там явно что-то еще поменяли. Про прошакшн развертывание fast API , идея хорошая. Конечно тесты на коленке, на своем ноуте, это все очень приблизительно. И нагрузка должна в идеале быть более разнообразной. Но 100 клиентов с такой интенсивностью вроде хватило чтобы мой комп нагрузить. Можно проверить, но там у меня уже сокеты в ОС кончаются , ошибки такие падают . Наверное уже другие инструменты нужны и не все на одном компе делать
@user-ch3de2wt5bАй бұрын
@@SeniorPomidorDeveloper не, с 25к до 7 это сильно слишком, имел в виду 25-7) 7к экономии в месяц
@AlexeyTeacherАй бұрын
но запросы же разные были + в джанге вы циклом проходили еще. Плюс интересно есть ли разница если использовать условный json_agg?
@SeniorPomidorDeveloperАй бұрын
Смотря где. Для sync и async я делал тесты чтобы абсолютно одинаковый был код (кроме конструкции await и того что за ними.) Разные виды сериализации вроде не особо влияют в этом случае.
@AlexeyTeacherАй бұрын
@@SeniorPomidorDeveloper в фактах у вас в один запрос, а в Джанго везде два, как то странно сравнивать, когда вы потом это ещё пилоном склеиваете
@SeniorPomidorDeveloperАй бұрын
Если вы имеете ввиду querset в котором prefetch related, то там два запроса . Причем абсолютно такие же как и в других тестах. Не верите - проверьте . Ссылка на репозиторий под видео
@AlexeyTeacherАй бұрын
@@SeniorPomidorDeveloperАаа, простите, на видео показалось, что на фастах 1 запрос. Тогда да все примерно одинаково. Хотя, не понятно, почему бы не сделать в один sql если все-равно голый используешь. На работе мне бы на ревью сразу бы сказали в один переписать...))
@SeniorPomidorDeveloperАй бұрын
@AlexeyTeacher это не возможно) когда связь как foreign key то можно сделать join , или он же select related. Когда это many to many то связь строится через третью таблицу (которая скрыта для Джанго) и тут уже никак без второго запроса не обойтись.
@humankind3098Ай бұрын
Что мешает справа написать так же 2 строчки кода на sqlalchemy? + потестить бы скорость сериализации pydantic и в django
@SeniorPomidorDeveloperАй бұрын
Не уместилось уже в видео, и так больше 30 мин, никто досмотреть не может .
@humankind3098Ай бұрын
@@SeniorPomidorDeveloper если не секрет, какой результат?)
@SeniorPomidorDeveloperАй бұрын
Я имею ввиду что после нескольких часов съемки понял что уже не влазит. А что мешает вам самому это потестить? Обязательно это должен делать парень из ютюба, пока вы кофе пьете? Быстро за работу!
@humankind3098Ай бұрын
@@SeniorPomidorDeveloper а как же банальная программистская лень?) лучше спрошу у chatgpt)
@SeniorPomidorDeveloperАй бұрын
🤣
@npc-r390Ай бұрын
С await gather интересный вариант, но методы не надо создавать внутри других методов, а их следовало объявить за пределами вьюхи. Это и могло замедлить время
@SeniorPomidorDeveloperАй бұрын
Сейчас проверил. Нет. Это не влияет. Разница в десятые процента.
@skyruptor337Ай бұрын
response time это конечно хорошо, но разве производительность обычно не в rps мерят? У siege это transaction rate получается. И самый большой получился у обычного gunicorn 4/2 с сериализоторами
@SeniorPomidorDeveloperАй бұрын
Rp/s тут пропорционально практически совпадает с Response time, по-тому что время тестирования для всех одинаковое, а кол-во удачных запросов 99.6% - 99.8% . Для видео в разговорном стиле просто удобнее было говорить про среднее время запроса.
@artemxyiКүн бұрын
Сравни какой нибудь Rustовский фреймворк(Actix, Axum, Ntex) с Fastapi