_ah/stats 中的 RPC 计时是否遗漏了什么？
Are the RPC timings in _ah/stats leaving something out?
我正在尝试了解在 AppEngine 中我可以在哪里减少特定请求的时间（将有数百万用户）。
这是我的 appengine.com 实例（不是我的本地开发服务器）的 RPC 计时。
甘特图显示处理程序中的 3 个 RPC 调用每次最多花费 25 毫秒：
但两者之间存在巨大差距。
所以我在每个 RPC 周围添加了一些日志消息，例如：
logging.debug('Starting 1st RPC')
tags = ndb.get_multi(tag_keys, use_cache=True, use_memcache=True)
logging.info('Finished 1st RPC, retrieved {} entities'.format(len(tags)))
上图请求的日志是：
2015-04-03 16:33:16.870 /api/v2/foo 200 1229ms 103kb Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.118 Safari/537.36 module=default version=3
D 2015-04-03 16:33:15.650 Starting 1st RPC
I 2015-04-03 16:33:15.670 Finished 1st RPC, retrieved 3 entities
D 2015-04-03 16:33:15.671 Starting 2nd RPC
I 2015-04-03 16:33:15.953 Finished 2nd RPC, retrieved 30 entities
I 2015-04-03 16:33:15.957 ...
D 2015-04-03 16:33:15.958 Starting 3rd PRC
I 2015-04-03 16:33:16.574 Finished 3rd RPC, retrieved 190 entities
I 2015-04-03 16:33:16.652 ...
I 2015-04-03 16:33:16.761 ...
I 2015-04-03 16:33:16.843 Saved; key: __appstats__:095600, part: 90 bytes, full: 15711 bytes, overhead: 0.001 + 0.066; link: http://foo.appspot.com/_ah/stats/details?time=1
显示 RPC 计时为 20 毫秒、282 毫秒、616 毫秒。
我的猜测是图表计时不考虑反序列化到模型对象或类似的东西？
根据数据存储管理员的说法，平均。从第 2 次和第 3 次调用返回的实体的实体大小分别为 5KB 和 1KB。
此外，图表显示第 3 个 RPC 在第一个之后开始约 600 毫秒，而日志显示第 1 和 3 之间仅过去了约 300 毫秒。
我不应该依赖 chart/stats 获得 hard/real 个数字吗？
My guess is that the chart timings do not account for deserialization
into the model object, or something like that?
正确 - 他们 严格 只针对 RPC 本身。
Also, the chart shows the 3rd RPC starting ~600 ms after the first,
while the logs show only ~300 ms elapsed between 1 & 3.
这 是 令人困惑的 -- 我有时看到相反的情况（并且在心理上将其归因于应用程序或线程被抢占并且图表仅考虑 "CPU" 而不是 "total elapsed" 时间）但从来没有你观察到的那种差异。
Should I not rely on the chart/stats for hard/real numbers?
我最近开始使用 Google Cloud Monitoring（来自 Stackdriver）玩游戏（仅 "playing"，因为它处于测试阶段），根据 https://cloud.google.com/monitoring/get-started#monitoring_app_engine_projects，我想知道它是否可以为您做得更好...
我正在尝试了解在 AppEngine 中我可以在哪里减少特定请求的时间（将有数百万用户）。
这是我的 appengine.com 实例（不是我的本地开发服务器）的 RPC 计时。
甘特图显示处理程序中的 3 个 RPC 调用每次最多花费 25 毫秒：
但两者之间存在巨大差距。
所以我在每个 RPC 周围添加了一些日志消息，例如：
logging.debug('Starting 1st RPC')
tags = ndb.get_multi(tag_keys, use_cache=True, use_memcache=True)
logging.info('Finished 1st RPC, retrieved {} entities'.format(len(tags)))
上图请求的日志是：
2015-04-03 16:33:16.870 /api/v2/foo 200 1229ms 103kb Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.118 Safari/537.36 module=default version=3
D 2015-04-03 16:33:15.650 Starting 1st RPC
I 2015-04-03 16:33:15.670 Finished 1st RPC, retrieved 3 entities
D 2015-04-03 16:33:15.671 Starting 2nd RPC
I 2015-04-03 16:33:15.953 Finished 2nd RPC, retrieved 30 entities
I 2015-04-03 16:33:15.957 ...
D 2015-04-03 16:33:15.958 Starting 3rd PRC
I 2015-04-03 16:33:16.574 Finished 3rd RPC, retrieved 190 entities
I 2015-04-03 16:33:16.652 ...
I 2015-04-03 16:33:16.761 ...
I 2015-04-03 16:33:16.843 Saved; key: __appstats__:095600, part: 90 bytes, full: 15711 bytes, overhead: 0.001 + 0.066; link: http://foo.appspot.com/_ah/stats/details?time=1
显示 RPC 计时为 20 毫秒、282 毫秒、616 毫秒。
我的猜测是图表计时不考虑反序列化到模型对象或类似的东西？
根据数据存储管理员的说法，平均。从第 2 次和第 3 次调用返回的实体的实体大小分别为 5KB 和 1KB。
此外，图表显示第 3 个 RPC 在第一个之后开始约 600 毫秒，而日志显示第 1 和 3 之间仅过去了约 300 毫秒。
我不应该依赖 chart/stats 获得 hard/real 个数字吗？
My guess is that the chart timings do not account for deserialization into the model object, or something like that?
正确 - 他们 严格 只针对 RPC 本身。
Also, the chart shows the 3rd RPC starting ~600 ms after the first, while the logs show only ~300 ms elapsed between 1 & 3.
这 是 令人困惑的 -- 我有时看到相反的情况（并且在心理上将其归因于应用程序或线程被抢占并且图表仅考虑 "CPU" 而不是 "total elapsed" 时间）但从来没有你观察到的那种差异。
Should I not rely on the chart/stats for hard/real numbers?
我最近开始使用 Google Cloud Monitoring（来自 Stackdriver）玩游戏（仅 "playing"，因为它处于测试阶段），根据 https://cloud.google.com/monitoring/get-started#monitoring_app_engine_projects，我想知道它是否可以为您做得更好...