Google App Engine 内存缓存性能低答案

【问题标题】：Google App Engine low memcache performanceGoogle App Engine 内存缓存性能低
【发布时间】：2012-10-30 19:30:46
【问题描述】：

Memcache 是解决方案绝对可以是任何东西的东西之一，而没有人真正给出一个像样的答案，也许是因为没有。所以我不是在寻找直接的答案，而只是为了让我朝着正确的方向前进。

对于一个典型的请求，这是我的 AppStats 信息：

因此，在总共 440 毫秒的请求中，我在内存缓存中花费了 342 毫秒。在这里，我认为 memcache 应该是闪电般的速度。我一定是做错了什么。

在我的管理控制台中查看我的内存缓存统计信息，我有这个：

Hit count:  3848
Miss count: 21382
Hit ratio:  15%

我不是这方面的专家，但我很确定 15% 很糟糕。

上面的典型请求有点过于详细，无法解释，但基本上，我创建并放置了一个新实体，该实体还更新并放置了一个父实体，该实体也更新并放置了与父实体关联的任何用户。

在所有这些过程中，我总是通过密钥获取，从不查询。哦，我正在使用 NDB，所以所有基本的memcache stuff is handled automatically。所以我从来没有在我的代码中自己手动接触过内存缓存。

有什么想法吗？

编辑：这是我的请求的细分

所以我只有 2 个数据存储获取和 2 个放置。其余的会自动处理 memcache 的东西。为什么要做这么多工作？手动处理这些东西会更好吗？

【问题讨论】：

如果不确切知道您在做什么以及您的数据模型是什么样的，就不可能给您任何好的建议。
@JasonHall 是的，我想。我正在使用 NDB，所以我没有手动处理任何内存缓存。都是自动的。所以我想知道是什么导致它在内存缓存中占用 342？即使在绝对最坏的情况下，memcache 真的应该花那么长时间吗？
您可能希望对内存缓存的内容/方式进行一些控制——将其留给 NDB 不会神奇地解决您的问题，特别是因为 NDB 不知道您要尝试什么做。例如，尽可能使用set_multi 而不是set 来批处理您的内存缓存请求。
@JasonHall 老实说，我并没有做任何疯狂的事情。这只是一堆获取和放置，全部通过键。一些使用 ndb.get_multi，而另一些则分散在各处。我认为对于这种基本行为，NDB 缓存可能只是处理它。无论如何，我看到的数字是不是很糟糕？这是我第一次使用 GAE，所以我没有什么可以与之比较的......
@JasonHall 不确定它是否有帮助，但请查看更新..

【解决方案1】：

让我们仔细看看您的数据。七次 memcache 写入所花费的时间与两次数据存储写入所花费的时间一样多。这实际上证明了 memcache 比 Datastore 快 3.5 倍。

如果对您的应用程序的典型请求需要更新至少三个数据库实体，然后更新更多实体（关联的用户），则您不能让此操作“闪电般快速”。当您读取条目的频率远高于写入条目时，Memcache 会有所帮助。如果对用户记录的读取和写入量相当，您应该考虑使用 turning cache off 进行此模型。

您也可以尝试asynchronous operations 和task queues。根据您的描述，您似乎尝试首先更新实体，并且仅在更新完成后才更新其父级，因为这是自然的。您可以同时运行这些；这可能需要一些重构，但这是值得的。

其次，更新“所有关联的用户”可能是，也许。推迟到后台产生的任务； Task Queues 有一个非常方便的界面。 “关联用户”不会立即更新，但他们可能不需要！但是，您的请求的延迟会更短。

【讨论】：

所以你的意思是，考虑到我更新实体的频率，这是 memcache 的预期行为吗？我尽可能使用异步操作。我还没有考虑任务队列，但这似乎是个好主意。
@mohabitar 我对 AppEngine 的体验是，每个系统调用都可以以非零概率“飙升”（例如，从通常的 10 毫秒到 50 毫秒）。因此，您调用的 RPC 调用越多，其中之一出现峰值的可能性就越大，从而给您带来更高的延迟。如果您在每次访问时更新 both 内存缓存和数据存储，您可能会为操作带来更高的峰值风险。如果在两次写入之间，您有大量在内存缓存级别解决的读取，则这种风险可能是合理的。如果你不这样做，你可能会更好地没有缓存。