Комментарии 5
Очень интересно:
- Почему запросы на алхимии были написаны именно так. Например зачем в тесте payment мы выгребаем на сторону клиента ВСЕ dirstricts чтобы потом просто сделать random.choice? Почему при этом не используются возможности алхимии для выгребания districts одновременно с whouse?
- Какой SQL код был сгенерирован для каждого случая.
- Были ли предприняты попытки оптимизировать запросы? Остался ли впереди тот же фрйемворк?
- Использовали ли индексы в БД для оптимизации работы сгенерированных запросов? Как изменились ли результаты теста?
Спасибо большое за замечания. Запросы ещё будут оптимизироваться. В данный момент, не исключаю возможности, что сами транзакции можно оптимизировать лучше, но даже сейчас структура Python кода транзакций одинакова для обоих ORM, так что уже уместно проводить сравнение.
По поводу индексов: в данный момент индексируются только primary и foreign ключи. На этапе разработки проверял скорость алхимии без индексации foreign keys, скорость менялась незначительно. Думаю, что это из-за относительно небольшого наполнения базы. В дальнейшем будет добавлено больше индексов будет и увеличено наполнение БД.
По поводу сгенерированных кодов согласен, было бы лучше их разместить. В данной статье я этого не стал делать, так как для некоторых транзакций может генерироваться код на 400+ строк. Я думаю разместить примеры сгенерированного SQL для транзакций в текстовых файлах в репозитории.
Одинаковый код — плохая предпосылка для сравнения производительности. Разные фреймворки имеют разные подходы и разные возможности оптимизации. В реальном нагруженном проекте ты БУДЕШЬ оптимизировать код, а вот сменить фреймворк вряд ли получится. Отсюда и просьба показать как будет выглядеть результат теста в случае оптимизированного под каждый фреймворк кода
Тестирование производительности Python ORM методом, основанном на бенчмарке TPC-C