Heroku 零星的高响应时间
Posted
技术标签:
【中文标题】Heroku 零星的高响应时间【英文标题】：Heroku Sporadic High Response Time 【发布时间】：2015-05-19 05:36:24 【问题描述】：这是非常具体的，但我会尽量简短：
我们正在 Heroku 上运行一个 Django 应用程序。三台服务器：
-
测试（1 个 web，1 个 celery dyno）
培训（1 个网，1 个芹菜测功机）
产品（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.resolve4,270ms
SessionMiddleware.process_request 2,750ms
渲染 login.html 1,230ms
WSGIHandler 1,390ms
以上是简单的调用，通常不会花费这么多时间
我把范围缩小到了：
过去几个月我们一直遇到这个问题，但现在我们正在扩展它需要修复。 任何想法都将不胜感激，因为我已经用尽了几乎所有 SO 或 Google 链接。
【问题讨论】：
这似乎是个好问题，但可能会在serverfault得到更好的答复 @jedwards 谢谢，但那里的用户评论说我应该把它移到 SO :) 哦，伙计——我不认为两者都有它是不合理的。听起来这可能是一个编程或部署问题——每个站点都有一个专门研究。 【参考方案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 提供的好处超过了偶尔的高响应时间，而且它们的定价多年来变得更好。如果您遇到同样的问题，“最佳解决方案”将是您的选择。当我听到更多消息时，我会更新这个答案。
祝你好运！
【讨论】：
很棒的发现，以及坚持下去的方法！这绝对符合我在应用程序中看到的描述。不过，我仍然非常高兴我现在在 Linode 上。 ;) 我们在这个问题上遇到了和其他人一样的问题，我也看到了这些奇怪的交换问题。我什至从来没有把两个和两个放在一起，一直盯着看，看看我是否能看到重叠的一圈。这是非常有帮助的，希望现在他们承认存在这个问题可以解决。 刚刚检查过我们也有类似的内存和滞后模式。 感谢您发布此信息。我们在使用 Rails 堆栈时也遇到了这个问题。切换到 Performance-M 实例在财务上并不是最好的方案。我们每天有几个小时的高峰期可能需要高性能的测功机，但是一天中剩下的时间两个 2x 测功机就足够了，可以使用 Adept 插件进行扩展。希望问题能尽快得到解决。 是的......几年后我认为这个问题没有得到解决。我在标准 1x LogEntries 上的一个 url 说通常在 30 毫秒内响应，每天几次峰值到 30 秒并触发超时。在不同项目中的其他一些 Heroku 应用程序中也看到了类似的结果——由 redis 缓存支持的非常简单的 API 端点通常在几毫秒内返回超时或非常接近 30 秒标记。 ...考虑迁移到部署到 DigitalOcean 的 Docker Cloud。我不喜欢 AWS 的定价 :(【参考方案2】：不确定这是否会有所帮助，但我现在在 Heroku 上使用 Rails 应用程序正在经历同样的事情——看似不确定的零星高请求时间。例如，HEAD New Relic 正常运行时间 ping 我的站点索引通常需要 2-5 毫秒，需要 5 秒，或者渲染我的站点登录，通常需要 12 秒亚秒。偶尔也会随机出现 30 秒超时。以下是 Heroku 的支持在我的情况下不得不说的（至少在某些情况下）：
今天早些时候的那个看起来像是重启后的一大块请求队列。如果你想避免这些，你可能想看看我们的Preboot feature。这将允许您在部署后启动一组匹配的 dyno，然后将请求交给它们，而不是跳过现有的 dyno 并强制请求排队。
我应该注意，这是 Heroku 的标准测功机重启之一，而不是我的部署或任何东西。尽管预启动页面上有警告，但我在几分钟前启用了它，所以我们将看看它是否对我的情况有任何影响。希望这可能会有所帮助，因为我也一直在为此烦恼！
【讨论】：
谢谢凯德！很高兴听到我并不孤单。我们的团队在部署期间经历了很长的响应时间，但我的上述问题在这些时间不会发生。 Heroku 支持尚未回复我。让我们互相关注！ 目前我们在 Heroku 上的应用程序也遇到了同样的情况（Logentries 警报显示的高响应时间和退出超时问题）。使我们深入研究了许多方面以试图弄清楚（在优化方面有积极的副作用......），但无法描述什么是确定性的，什么不是（在我们的水平上）。 作为后续，在开启预启动后，周末我仍然收到两个缓慢的请求通知。需要几秒钟才能加载的页面，当重新访问时，几乎立即加载。所以，这里仍然没有答案。我越来越多地考虑硬着头皮转移到 AWS，因为我即将用 Heroku 解决这个问题。 :( @Cade - 检查：有关情况的任何新信息？如果您迁移到 AWS，您是否仍然遇到此问题？ 我真的受够了，我搬到了 Linode。自从四月份搬到 Linode 以来，零星的缓慢响应时间已经完全消失了。额外的好处：我的响应时间和应用程序性能快了好几倍，而且我支付的费用减少了 78%。缺点：devops 现在是我的问题。以上是关于Heroku 零星的高响应时间的主要内容，如果未能解决你的问题，请参考以下文章