首页 > 解决方案 > 优化 REST Api 调用

问题描述

我正在使用一个调用来下载文件的遗留代码库。最好的办法是让它异步,但这暂时不是一个选择。

另一种选择是优化后端以修复超时。一些现有的调查显示,有 8 个 db 调用来做一件事。已更改为 1 db 调用。性能有所提高,但仍处于边缘。现在我要关注另外两个问题。

  1. 后端使用 ORM 从 prostgres 加载到 python 对象中。该对象包含约 30 个属性。与 6 个值相比,用这 30 个值构造一个对象的成本是多少(返回给用户的内容)

  2. 有 3 个 for 循环(虽然不是嵌套的),用于格式化、转换和将对象从一个对象转换为另一个对象。对于 50,000 个对象,这意味着某些指令正在运行 150,000 次。

现在基于 1 和 2,优先级是修复 2 还是修复 1。不幸的是,代码的设置方式,我无法在本地运行它来做任何基准测试。唯一的方法是更改​​代码,通过 PR 并部署到登台。所以我想在部署之前先看看要关注哪一个。

我个人认为应该将 3 个 for 循环修改为 1。(如果可能)与 ORM 优化相比。有什么想法吗?

标签: pythonpostgresqlflask

解决方案


我会说你应该专注于1。如果你的循环没有嵌套并且你没有在你的循环中做任何非常资源密集的事情,那么你应该很好。请记住,如果您的列表中有 1000 个项目和两个嵌套循环,则您有 1M 次迭代 (1000²)。150k 次迭代还不错。

另一方面,有时使用 ORM 会导致非常低效的 SQL 查询。您可以在数据库服务器中记录查询,并认为您可以更好地编写它们。

ORM 的一个典型问题是(取决于当然的实现)它使用如下查询

SELECT foo FROM bar WHERE id IN (1,2,3,4,5....48500).

您可以使用子查询轻松优化该代码,例如

SELECT foo FROM bar WHERE id IN (SELECT bar_id FROM othertable)

我喜欢 Postgresql 慢查询日志记录功能,看看哪些查询需要优化。


推荐阅读