代码之家  ›  专栏  ›  技术社区  ›  donut

谷歌应用引擎上的简单数据库查询占用大量CPU时间

  •  0
  • donut  · 技术社区  · 15 年前

    我对Google应用引擎和Python还比较陌生,但我刚刚发布了我的第一个真实网站。但是现在我发现一条路径比其他路径占用的CPU(和API CPU)时间要多得多。我把范围缩小到了导致问题的单个数据存储提取: Carvings.all().fetch(1000)

    在应用引擎仪表板下,它报告“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个,我简直无法想象为什么它如此昂贵。

    4 回复  |  直到 14 年前
        1
  •  2
  •   Peter Recore    15 年前
    • memcache,如果你还没有,特别是如果相同的雕刻将被一次又一次地提取。如果你总共只有90个,我可以想象他们都会很快进入缓存,然后你就应该是黄金了。

    • 你需要这些雕刻品的所有特性吗?例如,如果您只是显示一个雕刻列表,那么您可以有一个单独的实体,类似于只具有一些属性的雕刻摘要。这意味着你的模式被非规范化了,但有时候这就是你为速度付出的代价。

    另外,我假设这不是用户经常访问的第一页?如果是这样的话,可能是云在旋转一个新实例。

        2
  •  0
  •   dmazzoni    15 年前

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

    另外,考虑使用memcache。

        3
  •  0
  •   Nick Johnson    15 年前

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

        4
  •  0
  •   Richard Watson    15 年前

    可能是图像(和/或文本属性)需要时间将马歇尔加载到对象中,具体取决于这些属性的大小。

    一等奖:就像别人说的那样使用memcache。然后,开销只在第一次命中时发生。

    二等奖:我不知道你的图片被更改的频率和你可能拥有的图片数量,但是你可以考虑将它们作为静态文件上传,并在HTML中简单地链接到它们。然后它将只是一个从浏览器获取的HTTP——开销要低得多。