We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
根据django_debug_toolbar工具查询并分析,目前代码中存在的查询语句效率极其低下,如工艺模块的焊接接头工艺分析,对单个工艺分析的获取进行了52次SQL查询,消耗~82ms。主要原因在于serializer中多次使用类似obj.detail.weldingseam_set.count(),而该结果不会被Django缓存,导致大量SQL查询,该性能问题官方做出了解答:
obj.detail.weldingseam_set.count()
If you are going to need other data from the QuerySet, just evaluate it.
ERP/Process/serializers/process_serializers.py
Lines 613 to 670 in 3cfd47f
select_related和prefetch_related方法是Django提供的数据库查询优化方法,前者通过在数据库层面进行join操作减少查询数据所需的往返次数,后者通过关联关系预先获取当前查询集的外键信息,在Python层面进行'join',二者均能大幅提高性能,具体选用哪一种需要根据关联关系,select_related需要正向的外键关系,而prefetch_related同时支持正反向,但目前测试来看性能略低于select_related(可能由于数据量太小,数据库层面join操作耗时不多,有待研究)。
作为性能优化对比,以库存模块辅材领用台账为例:/api/auxiliary_material_apply_ledgers/。
/api/auxiliary_material_apply_ledgers/
查询列表操作耗时随着对象数量的增加呈线性增长,直至达到单页最大数量后,查询时间不再增加,当达到每页10个(单页最大数量),此时的查询操作进行82次SQL查询,耗时~145.32ms,平均单个台账的查询耗时~14.53ms。 原API代码:
ERP/Inventory/api/apply_ledger.py
Lines 27 to 31 in df906ed
时间不再随数量线性增长,此时任意数量(以10个对象为例)的查询操作均进行2次SQL查询,耗时~11.16ms,平均单个台账的查询耗时~1.12ms。 新API代码:
Lines 33 to 42 in 3cfd47f
The text was updated successfully, but these errors were encountered:
codingrabbitt
Spground
eyeeco
MoriatyC
oosprey
No branches or pull requests
根据django_debug_toolbar工具查询并分析,目前代码中存在的查询语句效率极其低下,如工艺模块的焊接接头工艺分析,对单个工艺分析的获取进行了52次SQL查询,消耗~82ms。主要原因在于serializer中多次使用类似
obj.detail.weldingseam_set.count()
,而该结果不会被Django缓存,导致大量SQL查询,该性能问题官方做出了解答:ERP/Process/serializers/process_serializers.py
Lines 613 to 670 in 3cfd47f
select_related和prefetch_related
select_related和prefetch_related方法是Django提供的数据库查询优化方法,前者通过在数据库层面进行join操作减少查询数据所需的往返次数,后者通过关联关系预先获取当前查询集的外键信息,在Python层面进行'join',二者均能大幅提高性能,具体选用哪一种需要根据关联关系,select_related需要正向的外键关系,而prefetch_related同时支持正反向,但目前测试来看性能略低于select_related(可能由于数据量太小,数据库层面join操作耗时不多,有待研究)。
作为性能优化对比,以库存模块辅材领用台账为例:
/api/auxiliary_material_apply_ledgers/
。优化前
查询列表操作耗时随着对象数量的增加呈线性增长,直至达到单页最大数量后,查询时间不再增加,当达到每页10个(单页最大数量),此时的查询操作进行82次SQL查询,耗时~145.32ms,平均单个台账的查询耗时~14.53ms。
原API代码:
ERP/Inventory/api/apply_ledger.py
Lines 27 to 31 in df906ed
优化后
时间不再随数量线性增长,此时任意数量(以10个对象为例)的查询操作均进行2次SQL查询,耗时~11.16ms,平均单个台账的查询耗时~1.12ms。
新API代码:
ERP/Inventory/api/apply_ledger.py
Lines 33 to 42 in 3cfd47f
The text was updated successfully, but these errors were encountered: