Question

我对Google App Engine和Python相当陌生，但我刚刚用它发布了我的第一个真实网站。但是现在我遇到的问题是一条路径使用的CPU（和API CPU）时间明显多于其他路径。我已将其缩小到导致问题的单个数据存储区提取：Carvings.all().fetch(1000)

在App Engine仪表板下，对于该路径的每个请求，它都非常可靠地报告“1040cpu_ms 846api_cpu_ms”。这似乎可能是我的客户在网站上遇到的一些反应迟钝的原因。

所以我无法弄清楚这个查询的代价是多么昂贵。以下是相关数据模型：

class Carving(db.Model):
    title = db.StringProperty(required=True)
    reference_number = db.StringProperty()
    main_category = db.StringProperty()
    sub_category = db.StringProperty()
    image = db.ReferenceProperty(CarvingImage)
    description = db.TextProperty()
    price = db.FloatProperty()
    size = db.StringProperty()
    material = db.StringProperty()
    added_at = db.DateTimeProperty(auto_now_add=True)
    modified_at = db.DateTimeProperty(auto_now=True)

在应用程序的其他地方，当我从数据存储区中提取此模型时，我会进行更多过滤，我猜这就是为什么它们不会造成任何麻烦。但是这个模型的实体总数刚刚超过90，我无法想象为什么这么贵。

Answer 1

Memcache，如果你还没有，特别是如果一次又一次地取出相同的雕刻。如果你只有90个，我想他们都会很快进入缓存，那么你应该是金色的。
您是否需要雕刻的所有属性？例如，如果你只是显示一个雕刻列表，你可以有一个单独的实体，就像CarvingSummary只有一些属性。这意味着您的架构已经非规范化，但有时这是您为速度付出的代价。

另外，我假设这不是用户总是会遇到的第一页？如果是这种情况，可能是云启动了一个新实例。

Answer 2

有时，如果您执行索引查询，而不是查询模型中的“所有”元素，您将获得更好的性能。

另外，请考虑使用memcache。

Answer 3

你真的需要1000个实体吗？ CPU时间或多或少与检索到的结果数呈线性关系，因此如果您实际上并不需要所有结果，则可能会浪费大量时间来获取和解码它们。

Answer 4

可能是需要时间加载的图像（和/或文本属性）。根据这些属性的大小，编组成对象。

一等奖：只要像别人说的那样使用memcache。然后只在第一次点击时产生开销。

二等奖：我不确定您的图片被更改的频率和可能的数量，但您可以考虑将它们作为静态文件上传，只需在HTML中链接到它们。然后它只是来自浏览器的HTTP GET - 开销要低得多。

Google App Engine上的简单数据库查询需要大量的CPU时间

4 个答案: