谷歌应用引擎过度数据存储小操作

Posted 2023-02-16

【中文标题】谷歌应用引擎过度数据存储小操作

【英文标题】：Google app engine excessive datastore small operations

【发布时间】：2013-04-01 03:59:34

【问题描述】：

我的网站有大约 50 个用户，我的小型数据存储操作过多。我正在积极地进行内存缓存，没有那么多记录，但我仍然获得数百万个小型数据存储操作。 Appstats 说成本是 0，但实际成本不是 0。 我基本上知道小型数据存储操作可能发生在哪里。

仅键操作：我这样做，但我将其内存缓存，直到数据未更改。另外，我的大多数键操作都有限制 = 100（这是最大值），因此要获得 12m 操作，我需要进行 120000 次调用（我假设获取 1 个键是 1 个小操作）。因为我每天大约有 60-70 次访问，这似乎有点过分了。 我只是无法弄清楚是什么导致了这么多操作。 Appstats 没有给我任何线索。

这是仪表板。

这是应用统计信息。

【问题讨论】：

你使用远程 API 吗？是否为您的整个应用启用了 appstats？

Yes appstats 是根据这个developers.google.com/appengine/docs/python/tools/… 启用的。第二个数字是RPC stats。

您的代码的一部分可能没有使用 appstats 包装器进行包装。您必须确保应用程序中的每个端点都使用它。例如，如果您使用 mapreduce，它不会使用应用统计信息。通过远程 API 执行的所有操作也不使用应用统计信息。 App Stats 仅将最近的 1000 个条目存储在 memcache 中，因此它甚至可能无法准确概述您的应用（尤其是最近出现的所有短期 memcache 条目问题）

【参考方案1】：

您是否使用了大量的counts？似乎这可以be a problem 导致过多的数据存储小操作。

我没有你的代码，但this answer 有一些建议，可以在遇到此问题时优化你的代码。

另外，看看一个类似的问题 - Google app engine excessive small datastore operations 以获得类似的答案

【讨论】：

谢谢你的回答，我没有做太多的计数，我尽可能缓存。无论如何，50 个用户的 1200 万个操作似乎有点不合时宜。我的代码一定会发生一些时髦的事情，我希望有一种方法可以在开发方面进行一些分析。我的代码超过 35KLOC，所以不能在这里发布。

当您说 appstats 时，您是在谈论 this，对吧？

是的，这正是我的意思，看看截图。

【参考方案2】：

我注意到这个老问题尚未解决，因此根据您的信息，这是另一个潜在原因。

在一个非常新的公共 Azure VM 实例 (xxx.cloudapp.net) 上运行我的 GAE SDK，我注意到有很多机器人流量试图找到一个公共的开源 CMS 或购物车的管理页面。我相信这是由于机器人利用 AXFR 请求或暴力检测子域。

确保您阻止了任何不需要的机器人流量，而不是为他们提供动态页面，从而更多地访问您的数据存储区。

同样的情况也可能是由于在这 50 个用户请求的每个页面上循环的恶意 AJAX 请求引起的。