【问题标题】:Google App Engine ndb query fetch_page very slow for small amount of entities对于少量实体,Google App Engine ndb 查询 fetch_page 非常慢
【发布时间】:2017-08-31 08:29:30
【问题描述】:

以下查询似乎花费了太长时间

t0 = time.time()

# Fetch the entities and return result with cursor
result, next_cursor, more = MyModel.query(MyModel.active == True, MyModel.offline == False).fetch_page(pagination, start_cursor=cursor)

logging.info(time.time() - t0)

在本地开发机器上耗时近 2 秒,模型中的实体少于 150 个

当使用大约 800 个实体时,检索前 250 个实体需要近 2 秒,然后检索其余的大约需要 4 秒。有两个单独的请求来检索实时机器上的每个集合。

我只在查询中设置了时间,因此在这些时间中没有考虑其他处理。

如果是这样,fetch_page 是否正常,是否有任何合理的替代方法可以实现相同的效果?

【问题讨论】:

  • 不要将开发服务器用作性能测量的基础。与生产运行时相比,它确实没有关系(由于实施)。在查看实际运行时检查您的第一个查询是否没有等待服务器启动。然后开始查看日志,看看每个部分需要多长时间。您不包括在查询之前或之后调用的任何代码,也不包括您对查询所做的任何事情。 Appengine 并没有这么慢。您也没有提供任何迹象表明您的模型有多大。
  • 蒂姆,这些是查询的时间,而不是我在查询之前或之后所做的。请参阅上面的代码段。我在本地开发服务器和实时服务器上都进行了测试,结果非常一致。

标签: python-2.7 google-app-engine app-engine-ndb


【解决方案1】:

我已经解决了这个问题。

我必须做的是获取我需要发送给客户端的模型实体的主要属性并将它们保存到另一个新模型中。

随后的查询不需要对属性进行任何相等性测试,只需一个直接的 fetch_page,并在 0.000469923019409 毫秒内返回更大的数据集,而其他查询则需要 4 秒。

所以问题显然在于模型实体包含并且必须检索的数据量。

唯一的缺点是我不得不进行大量的重新设计,并且在两个地方拥有相同的数据。如果不进行重大重新设计,就无法避免后者。

无论如何,今晚我是一个快乐的开发者。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2015-06-27
    • 1970-01-01
    • 1970-01-01
    • 2015-12-19
    • 2013-01-05
    • 1970-01-01
    • 1970-01-01
    • 2010-10-06
    相关资源
    最近更新 更多