5

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

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

在此处输入图像描述

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

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

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

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

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

在这一切中，我总是一键获取，从不查询。哦，我正在使用 NDB，所以所有基本的memcache 东西都是自动处理的。所以我从来没有在我的代码中自己手动接触过内存缓存。

有任何想法吗？

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

在此处输入图像描述

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

4

1 回答 1

6

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

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

您还可以尝试异步操作和任务队列。根据您的描述，您似乎尝试首先更新实体，并且仅在更新完成后才更新其父级，因为这是自然的。您可以同时运行这些；这可能需要一些重构，但这是值得的。

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

于 2012-10-30T20:11:06.070 回答