我该如何解决由App Engine生成的“请求等待了太长时间，导致尝试服务您的请求错误后中止请求”

Question

通常，我们每秒大约有2个请求。但是，在将通知推送给3000个用户之后，我们突然达到了120个请求/秒。不幸的是，这些用户中大约有一半收到5XX服务器错误，这意味着出现的一半用户正在获得空白页。大肆宣传之后，再也没有发生服务器错误。

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

我的问题是如何解决此问题？或者我应该在哪里继续寻找问题的根源。预先感谢！

Answer 1

您在哪看到5XX码？

我遇到了一个实例，该实例在启动时神秘地挂起并死亡：

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

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

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

您的问题与此略有不同，但寻找问题的步骤却是相同的：

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，他的评论使我找到了问题根源，这是因为我没有足够的min_idle_instances。一旦我在app.yaml的自动缩放部分中设置了足够数量的min_idle_instance，我就不会收到任何5XX服务器错误。

Answer 4

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