【问题标题】:How to analyze performance of Objectify?如何分析 Objectify 的性能?
【发布时间】:2016-10-18 23:28:25
【问题描述】:

Objectify 是 Google 的 API/服务,用于在 Google 数据存储中存储 Java 对象。起初,我的操作过去很快(低几十毫秒)。现在,它们变慢了(400-600 毫秒)。

Objectify 还将一个操作变成多个操作,例如查询在索引中查找实体 ID,然后从内存缓存中检索一些实体,从数据存储中检索其他实体。字段上的注释会影响创建的操作数。有很多地方可能会出现性能问题。

我如何才能深入了解 Objectify 在提高性能和减少计费方面的实际作用(通过触发越来越少的高效操作)?

我查看了 Objectify 文档并广泛搜索了网络。我一直无法找到诊断 Objectify 查询的方法。

【问题讨论】:

  • 您是否尝试过使用低数据存储 API 执行相同的查询?通过这种方式,您可以确定最慢的部分是数据存储本身还是 Objectify 框架
  • 您在执行什么操作?你要撤回所有实体吗?如果没有任何变化,那么数据大小可能发生了变化?
  • 我还没有学习低数据存储 API。我正在撤回整个实体。我可以看到发生了变化的是商店中的实体数量。索引不使用哈希,索引实体越多,哈希不应该变慢?

标签: java google-app-engine objectify


【解决方案1】:

查看 GAE RPC 调用的堆栈驱动程序分析,了解幕后情况。它会给你一个原始操作的列表。

确实没有那么多不明显的地方会出现性能问题。混合查询(将查询转换为仅键查询,然后进行批量获取)仅适用于 @Cache 实体。原理很简单——如果缓存实体是有效的,那么尽可能多地使用缓存可能是有效的。如果您不确定,请删除@Cache

除此之外,Objectify 只是将低级 Entity 对象转换为 POJO。它在这方面相当有效,但您当然可以构建病理案例。注意漫长而昂贵的生命周期方法(@OnLoad 和朋友)。嵌套列表列表等可以轻松创建 O(N^3) 操作。但是当您创建它们时,这些应该是显而易见的。特别是如果您在 Ref<?> 对象上使用 @Load。加载不是免费的。

【讨论】:

  • 谢谢。 stackdriver 分析正是我所寻找的。对于每个 HTTP 请求,它都会向我显示生成了哪些数据存储和内存缓存操作。这可能是它自己的问题。 stackdriver 时间线显示 Objectify 正在使用 memcache 满足所有数据。 memcache 操作花费了 4 毫秒,这是我对哈希查找的期望。这里是奥秘。我在 Objectify 调用之前和之后放置了一条日志记录行。整个 Objectify 调用耗时 200 毫秒。我怎样才能知道在这额外的 196 毫秒内发生了什么?
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2016-02-01
  • 2017-07-11
  • 1970-01-01
  • 2014-03-03
相关资源
最近更新 更多