Не знал. Правильно ли я понимаю, что в таком случае умельцу надо где-то раздобыть эквивалентое окружение (56 ядер и всё такое прочее) или они предоставляют возможность попробовать разные варианты настроек и выбрать лучшее? Условно, если я кину PR где увеличиваю число воркеров для фласка - как/когда я пойму как изменился результат теста?
Вообще не удивительно, что если они запускают 20 процессов обрабатывающий запросы по одному (ждущих ответа БД в каждом), что они медленнее чем 1000 корутин одновременно ждущих ответа БД. А таких условиях конечно wsgi будет медленнее asgi
В идеале, размер пула и количество воркеров должны подбираться исходя из конкретного приложения чтобы максимально эффективно утилизировать. Никому не интересно, что криво настроенное одно приложение работает медленее чем хорошо настроенное другое. Надо сравнивать два хорошо настроенных в одинаковых условиях эксплуатации.
А не подскажете, какие настройки пула соединекний с БД были в тестах multiple queries? Я вижу, что конкаренси на HTTP запроса - 512, но сколько у нас пул в сервере с базой и сколько у нас пул воркеров - непонятно.
granian - это конечно прикольно, но если с uvicorn вы можете запустить его из асинк функции (проведя нужную инициализацию) с помощью server.serve(). То с гранианом так уже не получится, он сам гоняет свой луп и никак иначе (по крайней мере среди стабильного апи)
RSGI в целом протокол странный. Описание очень скудное и такое ощущение что никто не задумывался об альтернативных реализациях.
DI хуже чем в фастапи (к счастью можно прикрутить сторонний и не страдать) и очень много фич которые названы терминами, которые были при реализации сильно искажены до полного нарушения концепции (я про репозитории и dto)
В чем именно выражается эта тяжесть? На самом деле каждый микросервис - это монолит производного размера. Что выбирать для его разработки зависит от ситуации. Мы прекрасно живём на работе с микросервисом на джанге, в том время как другие микросервисы написаны на других фреймворках и языках.
Нет под рукой книги, открыл Википедию. Приспособленец там сделан через фабрику. Зачем делать через глобальный Стейт - неясно, если только ради статьи.
Прототип юзаю для всяких "дефотнных конфигураций". Создал один экземпляр класса, настроил. А дальше конструируешь не с нуля, на базе него, меняя только то что передал юзер. Может быть не каждый раз нужно использовать, но подход полезный
Билдер в питоне действительно часто лишний из-за наличия keyword-аргументов функции, но на самом деле это очень удобная вещь, когда речь идёт о конструировании со сложной логикой. Query builder из ORM это буквально тот же паттерн.
Синглтон же - просто антипаттерн как и всякие мутабельные статические переменные (только хуже).
Простите, я не понимаю как вы собираетесь учитывать число в плурализации, если это буквально про числа. Контекст и падежи часто заданы прям в переводе, вы же не собираете предложение из отдельных слов. Но в любом случае, спасибо, ограничение либы понятно.
locale это не сторонняя библиотека, это встроенная. Если я правильно помню, в ней есть ограничения по падежам ("5 мая" получить можно, "май" - нельзя).
Имхо, падежи не меняются диамически, они не зависят от подставляемых данных. Вы просто формируете фразу сразу в нужном падеже. Но да, так мы ограничены в динамической сборке из кусков
Не знал. Правильно ли я понимаю, что в таком случае умельцу надо где-то раздобыть эквивалентое окружение (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
Смешались в кучу кони, люди
Нет под рукой книги, открыл Википедию. Приспособленец там сделан через фабрику. Зачем делать через глобальный Стейт - неясно, если только ради статьи.
Прототип юзаю для всяких "дефотнных конфигураций". Создал один экземпляр класса, настроил. А дальше конструируешь не с нуля, на базе него, меняя только то что передал юзер. Может быть не каждый раз нужно использовать, но подход полезный
Первая нужна чтобы при ошибке закрыть. А вторая нужна чтобы при отсутствии ошибок закрыть и обработать ошибку закрытия
Билдер в питоне действительно часто лишний из-за наличия keyword-аргументов функции, но на самом деле это очень удобная вещь, когда речь идёт о конструировании со сложной логикой. Query builder из ORM это буквально тот же паттерн.
Синглтон же - просто антипаттерн как и всякие мутабельные статические переменные (только хуже).
если выписать акууратно все детали - не будет
вы хотели сказать - так как нет четких правил, каждый будет понимать её как хочет?
нельзя, в большинстве случаев мы пишем код с использованием разных библиотек, а они очень разные
к черту детали, хочу бэкап своих данных в скворцах
Где можно посмотреть эти приложения?
Простите, я не понимаю как вы собираетесь учитывать число в плурализации, если это буквально про числа. Контекст и падежи часто заданы прям в переводе, вы же не собираете предложение из отдельных слов. Но в любом случае, спасибо, ограничение либы понятно.
locale это не сторонняя библиотека, это встроенная. Если я правильно помню, в ней есть ограничения по падежам ("5 мая" получить можно, "май" - нельзя).
Имхо, падежи не меняются диамически, они не зависят от подставляемых данных. Вы просто формируете фразу сразу в нужном падеже. Но да, так мы ограничены в динамической сборке из кусков
Минималистично API это, конечно, хорошо, но
Какие инструменты для переводчиков вы предлагаете?
Как происходит плурализация? (1 яблоко, 2 яблока, 5 яблок / 1 apple, 2 apples, 5 apples)
Как насчет локализации чисел? (1 000,15 vs 1,000.15)