Question

Memcache是解决方案绝对可以做到的事情之一，并且没有人真正给出了正确的答案，也许是因为没有。所以我不是在寻找直接的答案，但也许只是为了让我朝着正确的方向前进。

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

enter image description here

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

在管理控制台中查看我的memcache统计信息，我有：

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

我不是这方面的专家，但我很确定15％是可怕的。

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

在这一切中，我总是按键，从不查询。哦，我正在使用NDB，所以所有的基本memcache stuff is handled automatically。所以我从来没有在我的代码中亲自手动触摸memcache。

有什么想法吗？

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

enter image description here

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

Answer 1

让我们仔细看看你的数据。七个memcache写入花费了两个数据存储区写入的时间。这实际上证明了memcache比数据存储快3.5倍。

如果对您的应用程序的典型请求需要更新至少三个数据库实体 - 然后更新更多实体（与之关联的用户），则无法使此操作“快速闪电”。当您以比编写条目更频繁的方式阅读条目时，Memcache会有所帮助。如果对用户记录的读取和写入量相同，则应考虑turning cache off此模型。

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

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