如何解决从 App Engine 生成的“等待太久以尝试为您的请求提供服务错误后请求被中止”

Question

一般来说，我们每秒大约有 2 个请求。然而，在我们向 3000 个用户推送通知后，我们突然达到 120 个请求/秒。不幸的是，这些用户中大约有一半遇到了 5XX 服务器错误，这意味着出现的一半用户遇到了空白页。炒作消失后，再也没有发生服务器错误。

我做了一些研究，似乎是因为启动时间，即实例启动时间太长，因此中止。我检查了我的实例编号，创建了多达 90 个实例，但活动实例在一秒钟后从 40 下降到 0。这个问题只有在请求突然增加时才会出现，但我认为应用引擎应该能够处理这种类型的增加。

我的问题是如何解决这个问题？或者我应该在哪里继续挖掘以找到问题的根源。提前致谢！

Answer 1

您在哪里看到了哪些 5XX 代码？

我遇到了实例在启动时神秘挂起和死机的问题：

app engine instance dies instantly, locking up deferred tasks until they hit 10 minute timeout

这是由于我使用的第 3 方库在实例化期间试图绑定到端口，我最终编辑了该库的源代码。

在一个实例向 APNS 发送了大约 20 次推送通知后，我也遇到了崩溃，这是由于应用引擎版本的 python ssl 库中的内存泄漏。

您的问题与这些有点不同，但寻找问题的步骤感觉相同：

1. 通过将项目部署到不同的项目 ID 来设置沙盒并重现问题。制作一个脚本，在几分钟内从本地计算机发出数千个请求，并在此沙箱中执行此操作。
2. 注释掉你的代码，再次部署到沙箱，看看它是否仍然崩溃，重复直到你的脚本不再崩溃。

继续进行这样的消除过程应该会通过排除所有不会导致问题的因素来引导您找出导致问题的原因。

您也可以从相反的方向执行此操作，从“hello world”类型的项目开始，并系统地复制粘贴应用程序代码块，直到问题开始发生。

Answer 2

如果您遇到高流量，那么现在也许是您运行负载测试的好时机。尝试尽可能地模拟真实世界的流量，并尝试使用Stackdriver Trace 或通过分析代码和数据库操作中的请求处理来找到瓶颈。

还要检查 yaml 文件中的项目缩放设置，尤其是这些参数：

automaticScaling:
  coolDownPeriod: 120s
  cpuUtilization:
    targetUtilization: 0.5
  maxTotalInstances: 8
  minTotalInstances: 1

Answer 3

谢谢大家的帮助，我已经解决了问题。

这要归功于 Dan Cornilescu，他的 cmets 为我提供了找到问题根源的线索，这是因为我没有足够的 min_idle_instances。一旦我在 app.yaml 的自动缩放部分设置了足够数量的 min_idle_instance，我就没有收到任何 5XX 服务器错误。

Answer 4

不一定是解决方案，但值得检查：确保您在 Google 提供的环境变量指定的端口上进行监听。这为我解决了。