Heroku 零星的高响应时间

Question

这是非常具体的，但我会尽量简短：

我们正在 Heroku 上运行一个 Django 应用程序。三台服务器：

1. 测试（1 个 web，1 个 celery dyno）
2. 培训（1 个网，1 个芹​​菜测功机）
3. 产品（2 个网，1 个芹​​菜测功机）。

我们使用 Gunicorn 和 gevents 和 每个 dyno 上的 4 名工人。

我们正在经历零星的高服务时间。下面是 Logentries 的一个例子：

High Response Time:
heroku router - - at=info 
method=GET 
path="/accounts/login/" 
dyno=web.1 
connect=1ms 
service=6880ms 
status=200 
bytes=3562

我已经在谷歌上搜索了好几个星期了。我们无法随意复制，但每天会遇到 0 到 5 次这些警报。 值得注意的点：

• 在所有三个应用程序上发生（都运行类似的代码）
• 出现在不同的页面，包括404和/admin等简单页面
• 随机发生
• 以不同的吞吐量发生。我们的一个实例每天只驱动 3 个用户。它与睡眠测功机无关，因为我们使用 New Relic 进行 ping 操作，并且问题可能会在会话中发生
• 无法随意复制。我曾经亲身经历过这个问题。单击通常在 500 毫秒内执行的页面会导致 30 秒的延迟，并最终导致 Heroku 的 30 秒超时导致应用错误屏幕
• 高响应时间从 5000 毫秒到 30000 毫秒不等。
• New Relic 没有指出具体问题。以下是过去的几笔交易和时间：
  • RegexURLResolver.resolve 4,270ms
  • SessionMiddleware.process_request 2,750ms
  • 渲染 login.html 1,230ms
  • WSGIHandler 1,390ms
  • 以上是简单的调用，通常不会花费这么多时间

我把范围缩小到了：

1. This article on Gunicorn and slow clients
   • 我看到这个问题发生在慢速客户端上，但也发生在我们有光纤连接的办公室。
2. Gevent 和 async worker 玩得不好
   • 我们已切换到 gunicorn 同步工作器，但问题仍然存在。
3. Gunicorn 工作程序超时
   • 工作人员可能以某种方式在 null 状态下保持活动状态。
4. 工人/测功机不足
   • 没有任何迹象表明 CPU/内存/db 过度使用，New Relic 没有显示任何关于 DB 延迟的迹象
5. 吵闹的邻居
   • 在我与 Heroku 的多封电子邮件中，支持代表提到我的长请求中至少有一个是由于邻居吵闹，但不相信这是问题所在。
6. 子域 301
   • 请求正常通过，但随机卡在应用程序中。
7. Dynos 重启
   • 如果是这种情况，很多用户都会受到影响。另外，我可以看到我们的测功机最近没有重新启动。
8. Heroku 路由/服务问题
   • Heroku 服务可能没有宣传的那么好，这只是使用他们的服务的一个缺点。

过去几个月我们一直遇到这个问题，但现在我们正在扩展它需要修复。 任何想法都将不胜感激，因为我已经用尽了几乎所有 SO 或 Google 链接。

Answer 1

在过去 6 个月中，我一直与 Heroku 支持团队保持联系。通过反复试验进行了很长时间的缩小范围，但我们已经确定了问题。

我最终注意到，这些高响应时间与突然的内存交换相对应，即使我为 Standard Dyno 付费（它没有闲置），这些内存交换也是在我的应用最近没有收到流量时发生的。通过查看指标图表也很清楚，这不是内存泄漏，因为内存会停滞不前。例如：

在与他们的支持团队多次讨论后，我得到了这样的解释：

从本质上讲，一些后端运行时最终会出现应用程序组合，这些应用程序最终会使用足够的内存，运行时必须交换。发生这种情况时，运行时上的一组随机 dyno 容器被强制进行少量任意交换（请注意，这里的“随机”可能是具有最近未访问但仍驻留在内存中的内存的容器）。同时，使用大量内存的应用最终也会大量交换，这会导致运行时的 iowait 比正常情况更多。

自从这个问题开始变得更加明显以来，我们根本没有改变打包运行时的紧密程度，所以我们目前的假设是，问题可能来自客户从 2.1 之前的 Ruby 版本迁移到 2.1+ 版本。 Ruby 占了我们平台上运行的应用程序的很大一部分，Ruby 2.1 对其 GC 进行了更改，以内存使用换取速度（本质上，它的 GC 频率降低以获得速度提升）。这导致从旧版本 Ruby 迁移的任何应用程序的内存使用量显着增加。因此，之前保持一定内存使用水平的相同数量的 Ruby 应用现在将开始需要更多的内存使用。

这种现象与在平台上滥用资源的行为不端的应用程序相结合，达到了一个临界点，使我们陷入了我们现在看到的不应该交换测功机的情况。我们正在研究一些攻击途径，但就目前而言，上述很多内容仍然有点投机性。我们确实知道其中一些是由资源滥用应用程序引起的，这就是为什么迁移到 Performance-M 或 Performance-L dynos（具有专用的后端运行时）不应该出现问题的原因。这些测功机上唯一的内存使用将是您的应用程序的。所以，如果有交换，那是因为你的应用程序导致了它。

我相信这是我和其他人一直在经历的问题，因为它与架构本身有关，与语言/框架/配置的任何组合无关。

似乎没有其他好的解决方案 A）坚强起来，等待它结束或 B) 切换到他们的专用实例之一

我知道有很多人说“这就是你应该使用 AWS 的原因”，但我发现 Heroku 提供的好处超过了偶尔的高响应时间，而且它们的定价多年来变得更好。如果您遇到同样的问题，“最佳解决方案”将是您的选择。当我听到更多消息时，我会更新这个答案。

祝你好运！

Answer 2

不确定这是否会有所帮助，但我现在在 Heroku 上使用 Rails 应用程序正在经历同样的事情——看似不确定的零星高请求时间。例如，HEAD New Relic 正常运行时间 ping 我的站点索引通常需要 2-5 毫秒，需要 5 秒，或者渲染我的站点登录，通常需要 12 秒亚秒。偶尔也会随机出现 30 秒超时。以下是 Heroku 的支持在我的情况下不得不说的（至少在某些情况下）：

今天早些时候的那个看起来像是重启后的一大块请求队列。如果你想避免这些，你可能想看看我们的Preboot feature。这将允许您在部署后启动一组匹配的 dyno，然后将请求交给它们，而不是跳过现有的 dyno 并强制请求排队。

我应该注意，这是 Heroku 的标准测功机重启之一，而不是我的部署或任何东西。尽管预启动页面上有警告，但我在几分钟前启用了它，所以我们将看看它是否对我的情况有任何影响。希望这可能会有所帮助，因为我也一直在为此烦恼！