Переход с Python 3.10 на 3.13 означает колоссальное увеличение скорости на 42% с использованием на 20-30% меньше памяти.
Если бы всё было так просто, люди бы давно перешли. Я на своих тестах заметил ускорени 5%. В реальности многие приложения вообще не упираются в производительность питона, а скорее во взаимолдействие с БД (иначе бы их давно переписали на го)
А вот затраты на регулярные обновления вы не учли. Каждый релиз питон обычно сопровождается тем что надо обновлять и библиотеки, а там тоже мажорные изменения. В общем, нелегкая это работа. А если у вас нет большого количества автотестов, процесс ещё усложняется. А если автотесты есть - подумайте сколько вы тратите на их обслуживание (хотя бы время сервера) и сравните с тем что вы сэкономите после обновления.
Да, обновляться надо. Не потому что вы сэномить 42% денег на аренду сервера, а чтобы не остаться у богом забытого софта без поддержки и разработчиков. Переехать с 3.10 на 3.12 сейчас самое время. На 3.13 - кто знает, ML либы могут легко отставать на год в поддержке новой версии питона, каждый сам пусть решает.
Иногда можно переубедить человека в процессе собеса. А иногда можно записать в тетрадку и раз в полгода переспрашивать "а сейчас не надумали". Или отсутствие интереса может быть связано с конкретным аспектом и HR способен на него повлиять.
В песочнице, но вы можете расширять доступное ему api, даже если из коробки мало что доступно (а вообще, как-то же приложения на ReactNative работают). Выдавая права к ФС вы автоматом даете права всему прилжению включая все что он там evaluate делает.
как правило, на конференциях доклады продвинутого уровня и новичку на это врядли так уж нужно тратить время
По ощущениям на конференциях доклады весьма среднего уровня но со всякой спецификой. Если ты знаком с темой о которой идёт речь, тебе будет скорее смешно как люди это используют. А если не знаком, то непонятно что происходит
Ну вопрос же в том чтобы подобрать правильные параметры. Условно, чтобы понять сколько надо воркеров и размер пула, может понадобиться сотня экспериментов с замером производительности. Как их проводить?
Не знал. Правильно ли я понимаю, что в таком случае умельцу надо где-то раздобыть эквивалентое окружение (56 ядер и всё такое прочее) или они предоставляют возможность попробовать разные варианты настроек и выбрать лучшее? Условно, если я кину PR где увеличиваю число воркеров для фласка - как/когда я пойму как изменился результат теста?
Вообще не удивительно, что если они запускают 20 процессов обрабатывающий запросы по одному (ждущих ответа БД в каждом), что они медленнее чем 1000 корутин одновременно ждущих ответа БД. А таких условиях конечно wsgi будет медленнее asgi
В идеале, размер пула и количество воркеров должны подбираться исходя из конкретного приложения чтобы максимально эффективно утилизировать. Никому не интересно, что криво настроенное одно приложение работает медленее чем хорошо настроенное другое. Надо сравнивать два хорошо настроенных в одинаковых условиях эксплуатации.
А не подскажете, какие настройки пула соединекний с БД были в тестах multiple queries? Я вижу, что конкаренси на HTTP запроса - 512, но сколько у нас пул в сервере с базой и сколько у нас пул воркеров - непонятно.
granian - это конечно прикольно, но если с uvicorn вы можете запустить его из асинк функции (проведя нужную инициализацию) с помощью server.serve(). То с гранианом так уже не получится, он сам гоняет свой луп и никак иначе (по крайней мере среди стабильного апи)
RSGI в целом протокол странный. Описание очень скудное и такое ощущение что никто не задумывался об альтернативных реализациях.
DI хуже чем в фастапи (к счастью можно прикрутить сторонний и не страдать) и очень много фич которые названы терминами, которые были при реализации сильно искажены до полного нарушения концепции (я про репозитории и dto)
В чем именно выражается эта тяжесть? На самом деле каждый микросервис - это монолит производного размера. Что выбирать для его разработки зависит от ситуации. Мы прекрасно живём на работе с микросервисом на джанге, в том время как другие микросервисы написаны на других фреймворках и языках.
Если бы всё было так просто, люди бы давно перешли. Я на своих тестах заметил ускорени 5%. В реальности многие приложения вообще не упираются в производительность питона, а скорее во взаимолдействие с БД (иначе бы их давно переписали на го)
А вот затраты на регулярные обновления вы не учли. Каждый релиз питон обычно сопровождается тем что надо обновлять и библиотеки, а там тоже мажорные изменения. В общем, нелегкая это работа. А если у вас нет большого количества автотестов, процесс ещё усложняется. А если автотесты есть - подумайте сколько вы тратите на их обслуживание (хотя бы время сервера) и сравните с тем что вы сэкономите после обновления.
Да, обновляться надо. Не потому что вы сэномить 42% денег на аренду сервера, а чтобы не остаться у богом забытого софта без поддержки и разработчиков. Переехать с 3.10 на 3.12 сейчас самое время. На 3.13 - кто знает, ML либы могут легко отставать на год в поддержке новой версии питона, каждый сам пусть решает.
Иногда можно переубедить человека в процессе собеса. А иногда можно записать в тетрадку и раз в полгода переспрашивать "а сейчас не надумали". Или отсутствие интереса может быть связано с конкретным аспектом и HR способен на него повлиять.
Если сразу сказать HR "я пока не ищу работу, но прийти поговорить могу", то вроде бы всё честно
В песочнице, но вы можете расширять доступное ему api, даже если из коробки мало что доступно (а вообще, как-то же приложения на ReactNative работают). Выдавая права к ФС вы автоматом даете права всему прилжению включая все что он там evaluate делает.
Нет, приложение заранее должно быть написано с расчетом на подмену кода в будущем. Например так
Открываете WebView, дальше продолжать?
По ощущениям на конференциях доклады весьма среднего уровня но со всякой спецификой. Если ты знаком с темой о которой идёт речь, тебе будет скорее смешно как люди это используют. А если не знаком, то непонятно что происходит
Ну вопрос же в том чтобы подобрать правильные параметры. Условно, чтобы понять сколько надо воркеров и размер пула, может понадобиться сотня экспериментов с замером производительности. Как их проводить?
Не знал. Правильно ли я понимаю, что в таком случае умельцу надо где-то раздобыть эквивалентое окружение (56 ядер и всё такое прочее) или они предоставляют возможность попробовать разные варианты настроек и выбрать лучшее? Условно, если я кину PR где увеличиваю число воркеров для фласка - как/когда я пойму как изменился результат теста?
Ну то есть, всё таки, если у нас 1000 корутин спят на ожидании БД, то ждущих потоков будет только 56. Даже если субд способна 1000 обслужить?
Судя по тому что я вижу, настройки очень разные везде. Например для fastapi - MAX_POOL_SIZE = 1000//multiprocessing.cpu_count() https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/Python/fastapi/app_orm.py
А для фласк число воркеров - cput_count*2.5 https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/Python/flask/gunicorn_conf.py
Вообще не удивительно, что если они запускают 20 процессов обрабатывающий запросы по одному (ждущих ответа БД в каждом), что они медленнее чем 1000 корутин одновременно ждущих ответа БД. А таких условиях конечно wsgi будет медленнее asgi
В идеале, размер пула и количество воркеров должны подбираться исходя из конкретного приложения чтобы максимально эффективно утилизировать. Никому не интересно, что криво настроенное одно приложение работает медленее чем хорошо настроенное другое. Надо сравнивать два хорошо настроенных в одинаковых условиях эксплуатации.
А не подскажете, какие настройки пула соединекний с БД были в тестах multiple queries? Я вижу, что конкаренси на HTTP запроса - 512, но сколько у нас пул в сервере с базой и сколько у нас пул воркеров - непонятно.
да, но
granian - это конечно прикольно, но если с uvicorn вы можете запустить его из асинк функции (проведя нужную инициализацию) с помощью server.serve(). То с гранианом так уже не получится, он сам гоняет свой луп и никак иначе (по крайней мере среди стабильного апи)
RSGI в целом протокол странный. Описание очень скудное и такое ощущение что никто не задумывался об альтернативных реализациях.
Лучше такое ТЗ писать на формализируемом языке, который минимально можно понять неоднозначно.
Нужна пасека
DI хуже чем в фастапи (к счастью можно прикрутить сторонний и не страдать) и очень много фич которые названы терминами, которые были при реализации сильно искажены до полного нарушения концепции (я про репозитории и dto)
В чем именно выражается эта тяжесть? На самом деле каждый микросервис - это монолит производного размера. Что выбирать для его разработки зависит от ситуации. Мы прекрасно живём на работе с микросервисом на джанге, в том время как другие микросервисы написаны на других фреймворках и языках.
Податься через сайт https://careers.nebius.com
Смешались в кучу кони, люди