U
смотря какая бизнес логика, при бенчмарке на хело ворлд дальше милисекунд не зайдет +)
Size: a a a
2019 April 26
🔐
User
40-60к это небольшое количество, тебе возможно raw query для производительности нужно писать, и изначально смотреть какие связи, мб орм что лишнего нагенерило
Да там префетчи дофига тянут за собой, сделал через prefetch_related, вообще 30 секунд отвечало, потом нагуглил что лучше класс Prefetch юзать, упало до вышеописанного времени
🔐
Но все равно недостаточно быстро
U
операция на выборку?
🔐
User
операция на выборку?
на сохранение связанных записей в память, чтоб при вызове лишних запросов в бд не было
w
может нужно добавить индексов для полей по которым идёт выборка?
🔐
может нужно добавить индексов для полей по которым идёт выборка?
тоже идея, надо пробнуть, но вряд ли это до миллисекунд сократит ответ
🔐
может нужно добавить индексов для полей по которым идёт выборка?
вообще, у меня вопрос по железу
🔐
Сильно ли бустанет если я ядер добавлю?
U
запрос к базе? вообще не бустанет
w
вообще ничо не изменится
U
индексы могут в 10 раз увеличить скорость, на 10кк записей около секунды уходит, но в таблице без связей, вообще нужно больше деталей про предметную область
AO
будущее за либами, а не за фреймворками)
AO
а фреймворки - это будет восприниматься широко, как "набор либ и рекомендаций по работе с ними"
AO
по сути, PaaS'ы - это фреймворки
U
херня, проблема джанго не в том что он фреймворк
AO
User
херня, проблема джанго не в том что он фреймворк
в этом тоже: время тратит не туда
AO
вот был бы отдельно Django ORM
AO
больше бы времени уделялось именно ему
U
active record плохой паттерн