除了 RPC 调用之外,还有什么原因会导致我的 App Engine 程序花费这么长时间
我正在尝试优化 GAE 中的页面加载性能,但我有点困惑为什么要花这么长时间来提供页面服务。
当我第一次运行 appstats 时,我发现该页面正在调用大约 500-600 个 RPC 调用。我现在已经将其减少到 3。
但是,我仍然在 App Stats 中看到大量的额外时间。我网站上的另一个页面(使用相同的 django 框架 + 模板)在大约 60 毫秒内加载,对一个小数据集执行一个小查询。
问题是,这个开销是多少,我应该在哪里寻找问题点?
请求中的数据大约有 350 条记录,每条记录大约有 30 个属性。我对数据调用本身占用数据存储 API 时间很满意,但这是我感到困惑的另一次时间。数据确实通过一个更大的迭代器进行逐步处理,现在我对大多数请求使用了 fetch 来保持 RPC 调用,并确保数据在内存中而不是在运行时被查询。
慢速请求 - 查看所有额外的蓝色
匹配
快速请求,RPC 蓝色与整体蓝色
编辑
好,所以我创建了一个名为 FastModel 的新模型,并将页面所需的最少项目复制到其中,这样它就可以加载速度尽可能快这是可能的,而且确实会产生很大的影响。模型上似乎有一些东西会减慢速度。将进一步调查。
I'm trying to performance optimize a page load in GAE, and I'm a bit stumped what is taking so long to serve the page.
When I first got appstats running I found the page was calling about 500-600 RPC calls. I've now got that down to 3.
However, I'm still seeing a massive load of extra time in App Stats. Another page on my site (using the same django framework + templating) loads in about 60ms, doing a small query to a small data set.
Question is, what is this overhead, and where should I be looking for trouble points?
The data in the request has about 350 records, and about 30 properties per record. I'm cool with the data call itself taking the datastore api time, but it's the other time I'm confused about. The data does get stepped through a biggish iterator, and I've now used fetch on most of these requests to keep the RPC call down, and make sure things are in memory rather than being queried as they go.
Slow Request - Look at all the extra blue
Fast Request , RPC blue is matched against overall blue
EDIT
OK, so I have created a new model called FastModel, and copied the bare minimum items needed for the page to it, so it can load as quickly as possible, and it does make a big difference. Seems there are things on the Model that slow it all down. Will investigate further.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
反序列化 350 条记录(尤其是大记录)需要很长时间。这可能是占用您大部分执行时间的原因。
Deserializing 350 records, especially large ones, takes a long time. That's probably what's taking up the bulk of your execution time.