4

概述：

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

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

流动：

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

问题：

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

解决方案？

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

更改为 Unicorn + Nginx并激活 Upload Module（这样 dyno 仅在上传完成后接收请求 - Unicorn + Rails + Large Uploads）。真的有可能吗？

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

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

其他...

4

2 回答 2

1

有关此问题的更多信息。

来自 Rapgenius： http: //rapgenius.com/Lemon-money-trees-rap-genius-response-to-heroku-lyrics

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

“请求在 dyno 级别的队列中等待，”一位 Heroku 工程师告诉我们，“然后很快得到服务（因此 Rails 日志看起来很快），但由于队列中的等待，整体时间变慢了。”</ p>

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

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

在过去的几年中，Heroku 客户偶尔会报告 Heroku 出现无法解释的延迟。延迟的原因有很多——其中一些与 Heroku 无关——但直到本周，我们还没有在这些报告中看到一个共同点。我们现在知道，我们在 Bamboo 和 Cedar 堆栈上的路由和负载平衡机制为我们的 Rails 客户带来了延迟问题，这体现在几个方面，包括：

  • 某些请求的无法解释的高延迟
  • 报告的排队和服务时间指标与观察到的现实不匹配
  • 记录和观察到的行为之间的差异

对于在 Bamboo 堆栈上运行的应用程序，这些问题的根本原因是 Bamboo 堆栈上路由的性质以及路由集群的逐渐、水平扩展。在 Cedar 堆栈上，根本原因是 Cedar 针对并发请求路由进行了优化，而某些框架（如 Rails）在其默认配置中不是并发的。

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

  • 正确记录路由在 Bamboo 堆栈上的工作方式
  • 了解我们的客户所经历的服务降级并采取纠正措施
  • 识别并纠正从路由层报告并由第三方工具显示的混淆指标
  • 清楚地传达我们路由服务的产品策略
  • 为客户提供从 Bamboo 上的非并发应用程序到 Cedar 上的并发 Rails 应用程序的升级路径
  • 兑现 Heroku 的承诺，让您专注于开发应用程序，而我们担心基础架构

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

  • 改进我们的文档，使其准确反映我们的服务在 Bamboo 和 Cedar 堆栈中的工作方式
  • 删除 Heroku 或 New Relic 等合作伙伴服务报告的不正确和令人困惑的指标
  • 添加让客户确定排队对应用程序响应时间的影响的指标
  • 提供其他工具，开发人员可以使用这些工具来增加我们的延迟和排队指标
  • 努力在 Cedar 上更好地支持并发请求 Rails 应用程序
  • 这篇博文的其余部分解释了我们路由基础设施的技术细节和历史、我们在此过程中做出的决策背后的意图、我们所犯的错误以及我们认为的前进道路。
于 2013-03-12T16:11:12.090 回答
0

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

Nginx 不适用于 heroku，所以这是没有选择的。

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

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

于 2012-09-24T16:21:46.860 回答