Heroku、H12 和直通上传超时答案

【问题标题】：Heroku, H12 and passthrough upload timeoutsHeroku、H12 和直通上传超时
【发布时间】：2012-09-24 16:14:47
【问题描述】：

概述：

我有一个照相亭，可以拍照并将它们发送到我的网络应用程序。然后我的网络应用程序存储用户数据并将图片发送到用户 facebook 个人资料/粉丝页面。

我的网络应用运行 Ruby on Rails @ Heroku Cedar 堆栈。

流程：

我的 web 应用程序通过 POST（如 Web 表单）从 photobooth 接收照片。
展位等待服务器响应。如果上传失败，会重新发送图片。
只有在 Facebook 上传完成后才会触发来自 webapp 的响应。

问题：

Webapp 仅在所有处理完成后才将数据发送到 photobooth。很多时候这将在 30 秒后发生。这会导致 Heroku 触发 H12 - Timeout。

解决方案？

在上传文件时保持请求处于活动状态（返回一些响应数据以防止 heroku 触发 H12 - https://devcenter.heroku.com/articles/http-routing#timeouts）。 - 可能吗？如何在 Ruby 中实现这一点？

改成 Unicorn + Nginx 并激活上传模块（这样 dyno 只会在上传完成后接收请求 - Unicorn + Rails + Large Uploads）。真的可以吗？

使用 rack-timeout gem。这会使我的很多直通上传失败，所以这些照片永远不会发布到 Facebook 上，对吧？

更改架构。 直接上传到 S3，旋转工作人员检查上传到 S3 存储桶的新图片，下载它们并将它们发送到 Facebook。 - 这个可能是最好的一个，但需要很多时间和精力。从长远来看，我可能会这样做，但我现在正在寻找一个快速的解决方案。

其他...

【问题讨论】：

这个过程的哪一部分需要 30 秒？这些照片有多大？
整个过程。从图片上传（启动到 webapp）直到图片发布到 Facebook。
...当然，但是这些时间都去哪儿了？如果你不知道它们为什么慢，就很难加快速度。 Heroku 服务器速度快且连接良好；移动一张照片不需要 30 秒。
我认为当展位连接（它使用移动互联网连接，而巴西的那些并不真正可靠）断开时会发生这种情况。所以照片上传卡住了，服务器一直在等待上传。然后展位重新连接并连接到另一个测功机以发送照片，再次下降并阻止第二个测功机......等等

标签： ruby-on-rails-3 file-upload heroku nginx timeout

【解决方案1】：

十天前，由于服务于我们编译的一个小问题 javascript，我们开始运行很多 ab 基准测试。我们注意到我们得到的数字一直比数字差 Heroku 及其分析合作伙伴 New Relic 向我们报告。为一个静态版权页面，例如，Heroku 报告平均响应时间40ms；我们的工具说 6330ms。什么可以解释差别这么大？

“请求在 dyno 级别的队列中等待，”一位 Heroku 工程师告诉我们，“然后被快速提供服务（因此 Rails 日志看起来很快），但由于队列中的等待，整体时间较慢。”

在测功机级别排队等候？什么？

来自 Heroku： https://blog.heroku.com/archives/2013/2/16/routing_performance_update

在过去的几年里，Heroku 客户偶尔会在 Heroku 上报告了无法解释的延迟。造成的原因有很多延迟——其中一些与 Heroku 无关——但在此之前本周，我们未能在这些报告中看到一个共同点。我们现在知道我们在Bamboo上的路由和负载均衡机制和 Cedar 堆栈为我们的 Rails 客户带来了延迟问题，这以多种方式表现出来，包括：

某些请求的无法解释的高延迟

报告的排队和服务时间指标与观察到的现实不匹配

记录的行为与观察到的行为之间存在差异

对于在 Bamboo 堆栈上运行的应用程序，这些问题的根本原因问题是 Bamboo 堆栈上路由的性质以及路由集群逐渐横向扩展。在雪松上堆栈，根本原因是 Cedar 已针对并发请求路由，而某些框架，如 Rails，则不是在默认配置中并发。

我们希望 Heroku 成为构建、部署和扩展 Web 和移动应用程序。在这种情况下，我们没有兑现承诺。我们未能：

正确记录路由在 Bamboo 堆栈上的工作原理

了解我们的客户所经历的服务质量下降并采取纠正措施

识别并更正路由层报告并由第三方工具显示的混淆指标

清楚地传达我们路由服务的产品策略

为客户提供从 Bamboo 上的非并发应用程序到 Cedar 上的并发 Rails 应用程序的升级路径

兑现 Heroku 的承诺，让您专注于开发应用，而我们则担心基础架构

我们将立即采取以下措施：

改进我们的文档，使其准确反映我们的服务在 Bamboo 和 Cedar 堆栈中的工作方式

删除 Heroku 或 New Relic 等合作伙伴服务报告的不正确和令人困惑的指标

添加指标让客户确定排队对应用程序响应时间的影响

提供其他工具，开发人员可以使用这些工具来增加我们的延迟和排队指标

努力在 Cedar 上更好地支持并发请求 Rails 应用程序

本博文的其余部分解释了我们路由基础架构的技术细节和历史，以及决策背后的意图我们一路走来，我们犯的错误以及我们认为的前进的道路。

【讨论】：

我从 heroku 那里得到了一些关于这个问题的很好的回应，如果不是停机的话，这至少会花费我们一些时间和金钱。他们表示他们“不会修复他们的路由器”，因为他们“对他们在设计它时做出的技术决策感觉非常好”。但是，他们将以两倍的价格提供具有两倍内存的 dyno，并且他们现在推荐 Unicorn 作为 cedar 上的 Rails 应用服务器。 Unicorn 本质上是在内部路由请求，在单个测功机上同时处理 2-4 个请求。 FWIW。

【解决方案2】：

1) 您可以使用 Unicorn 作为您的应用服务器，并将 unicorn master 杀死工作人员之前的超时设置为大于您的请求所需的秒数。这是一些example setup，您可以在其中看到 30 秒的超时。

Nginx 不能在 Heroku 上运行，所以没有选择。

2) 更改架构也可以很好地工作，尽管我会选择一个选项，而不是上传流量不会阻塞我自己的服务器，例如TransloadIt。它们将帮助您将图片发送到 S3 作为示例，并进行自定义转换、裁剪等，而无需添加额外的测功机，因为您的进程被文件上传阻塞。

添加：3）架构的另一个变化是只在一个动作中处理接收部分，并将上传到 facebook 的任务交给 后台工作人员（使用例如Sidekiq)。

【讨论】：

我必须将 Unicorn 超时设置为 120 秒，否则我会遇到与 rack-timeout 相同的问题，对吗？对于直接上传，我考虑的是 CarrierWeave Direct。我以前用过。
我不会比较 rack-timeout 和 unicorn workers 的超时时间。 Unicorn 的工作原理是这样的：在一个 heroku dyno 上，有一个主进程和三到四个工作进程。主子进程从不处理请求，他只监督工作子进程在它们卡住时杀死它们，也就是说，它们完成对未在指定超时内的 Web 请求的响应。所以 120 秒的超时可能会很好。
关于您的编辑.. 要做到这一点，我仍然需要将文件保存在 heroku 以外的其他位置，因为 heroku 不允许我访问文件系统。
Heroku 确实允许您访问文件系统——它只是不能保证您写入文件系统的内容会在任何特定时间段内持续存在。只要 dyno 保持活动状态，文件就会在 dyno 的文件系统上保持活动状态，这通常是 24 小时左右。
我不知道。但是，即使您要将文件写入测功机的文件系统，您也无法从通常在单独的测功机中运行的后台工作进程访问它。