数据存储和内存缓存操作 (GAE) 的高度可变性能答案

【问题标题】：Highly variable performance on datastore and memcache operations (GAE)数据存储和内存缓存操作 (GAE) 的高度可变性能
【发布时间】：2013-07-12 02:16:46
【问题描述】：

我正在尝试优化 GAE 的性能，但一旦部署，我会得到非常不稳定的结果。很难看出每个优化是否真的有效，因为数据存储和内存缓存操作需要一个非常可变的时间（对于相同的操作，它的范围从毫秒到秒）。

对于这些测试，我是唯一一个通过刷新主页在应用程序上只发出一个请求的人。没有其他人/流量发生（除了我自己的浏览器从页面请求图像/css/js 文件）。

编辑：为了确保丢弃不是由于来自浏览器的并发请求（images/css/js），我通过仅请求带有 urllib2.urlopen 的页面来重做测试()。问题仍然存在。

我的问题是：

这是一个非常缓慢的数据存储获取（memcache 刚刚刷新）： Full size

这是一个非常慢的 memcache 获取（因为之前的请求，东西被缓存了）： Full size

这是一个缓慢但更快的 memcache 获取（与前一个相同的重现步骤，不同的调用很慢）： Full size

【问题讨论】：

您的数据存储获取速度非常慢！您尝试运行的查询是什么，它是否取决于 zig-zag 连接？
它只是具有各种字符串、整数、引用的实体（模型中没有 blob）。我可以运行两次测试并获得 10 毫秒的查询或获取，然后再次运行并在 7 秒内运行，再运行一次并获得 200 毫秒。至少如果它一直很慢，我会知道我的查询/数据很糟糕。
你确定你有一个运行缓慢的请求实例，并且你没有测量启动时间
是的，有一个正在运行的实例。如果没有，日志显示：该请求导致为您的应用程序启动了一个新进程，从而导致您的应用程序代码首次加载。因此，与您的应用程序的典型请求相比，此请求可能需要更长的时间并使用更多的 CPU。 - 我也怀疑启动实例是否会出现在 appstats 中的单个数据存储/内存缓存操作中。
你在使用 NDB 吗？如果是，您是否尝试异步执行某些数据存储操作。这样，您将只依赖于最慢操作的延迟（而不是累积的延迟）。相关：您可能还想看看proppy-appstats.appspot.com，它介绍了不同的数据存储优化模式。

【解决方案1】：

为了回答您的问题，

1) 是的，由于共享网络，您可以预期远程调用会有所不同；

2) 您最常看到差异的地方是数据存储请求——请求越大/越远，您看到的差异就越大；

3) 这里有一些选项供您选择：

您似乎正试图从数据存储/内存缓存中获取大量数据。您可能需要重新考虑查询和缓存，以便它们检索较小的数据块。您的应用是否需要针对单个请求的所有数据？

如果应用程序确实需要处理每个请求的所有数据，另一种选择是使用后台任务（cron、任务队列等）对其进行预处理并将结果放入内存缓存中。提供页面的请求应该简单地从内存缓存中挑选出正确的部分并组装页面。

@proppy 建议使用 NDB 是一个很好的建议。将串行查询重写为并行查询需要一些工作，但异步调用可以节省大量资金。如果您可以从并行任务中受益（使用地图），那就更好了。

【讨论】：

我接受你的回答，因为你和 proppy 分享了很好的链接和建议，以及一般的良好做法。我没有使用 NDB，但现在正在考虑它（这是一个很大的变化）。现在可悲的是：我禁用了 appstats 并且超慢的操作完全消失了。事情仍然是可变的，但它们在整个页面（缓存中没有任何内容）保持在 300-500 毫秒内，而在缓存内容时保持在 120-250 毫秒。此外，appstats 在 memcache 中为 1 个请求占用了 500k，没有它，我的第一个请求将所有内容存储在 52k 中。使用 appstats 的最快加载无缓存是 1000 毫秒，没有 appstats：300 毫秒。