运维开发网

ruby-on-rails-3 – Heroku,H12和passthrough上传超时

运维开发网 https://www.qedev.com 2020-07-19 20:33 出处:网络 作者:运维开发网整理
概述: 我有一个photobooth拍照并将它们发送到我的网络应用程序. 然后我的Web应用程序存储用户数据并将图片发送到用户的Facebook个人资料/粉丝页面. 我的网络应用程序运行Ruby on Rails @ Heroku Cedar堆栈. 流: >我的网络应用程序通过POST(如网络表单)从照相馆收到照片. >展位等待服务器响应.如果上传失败,它将再次发送图片. >仅在Facebook上
概述:

我有一个photobooth拍照并将它们发送到我的网络应用程序.

然后我的Web应用程序存储用户数据并将图片发送到用户的Facebook个人资料/粉丝页面.

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

流:

>我的网络应用程序通过POST(如网络表单)从照相馆收到照片.

>展位等待服务器响应.如果上传失败,它将再次发送图片.

>仅在Facebook上传完成后才会触发来自webapp的响应.

问题:

所有处理完成后,Webapp仅将数据发送到photobooth.很多时候这将在30秒后发生.这导致Heroku发射H12 – 超时.

解决方案?

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

更改为Unicorn Nginx并激活上传模块(这样dyno仅在上传完成后收到请求 – Unicorn + Rails + Large Uploads).真的有可能吗?

使用rack-timeout gem.这会让很多我的passthrough上传失败,所以图片永远不会在Facebook上发布,对吧?

改变架构.将上传内容直接发送到S3,旋转工作人员检查上传到S3存储桶的新图片,下载并将其发送到Facebook. – 这可能是最好的一个,但需要花费大量的时间和精力.我可能会长期坚持下去,但我现在正在寻找快速解决方案.

其他…

有关此问题的更多信息.

来自Rapgenius:

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

Ten days ago, spurred by a minor problem serving our compiled

javascript, we started running a lot of ab benchmarks. We noticed that

the numbers we were getting were consistently worse than the numbers

reported to us by Heroku and their analytics partner New Relic. For a

static copyright page, for instance, Heroku reported an average

response time of 40ms; our tools said 6330ms. What could account for

such a big difference?

“Requests are waiting in a queue at the dyno level,” a Heroku engineer

told us, “then being served quickly (thus the Rails logs appear fast),

but the overall time is slower because of the wait in the queue.”

Waiting in a queue at the dyno level? What?

来自Heroku:

https://blog.heroku.com/archives/2013/2/16/routing_performance_update

Over the past couple of years Heroku customers have occasionally

reported unexplained latency on Heroku. There are many causes of

latency—some of them have nothing to do with Heroku—but until this

week, we failed to see a common thread among these reports. We now

know that our routing and load balancing mechanism on the Bamboo and

Cedar stacks created latency issues for our Rails customers, which

manifested themselves in several ways, including:

  • Unexplainable, high latencies for some requests
  • Mismatch between reported queuing and service time metrics and the observed reality
  • Discrepancies between documented and observed behaviors

For applications running on the Bamboo stack, the root cause of these

issues is the nature of routing on the Bamboo stack coupled with

gradual, horizontal expansion of the routing cluster. On the Cedar

stack, the root cause is the fact that Cedar is optimized for

concurrent request routing, while some frameworks, like Rails, are not

concurrent in their default configurations.

We want Heroku to be the best place to build, deploy and scale web and

mobile applications. In this case, we’ve fallen short of that promise.

We failed to:

  • Properly document how routing works on the Bamboo stack
  • Understand the service degradation being experienced by our customers and take corrective action
  • Identify and correct confusing metrics reported from the routing layer and displayed by third party tools
  • Clearly communicate the product strategy for our routing service
  • Provide customers with an upgrade path from non-concurrent apps on Bamboo to concurrent Rails apps on Cedar
  • Deliver on the Heroku promise of letting you focus on developing apps while we worry about the infrastructure

We are immediately taking the following actions:

  • Improving our documentation so that it accurately reflects how our service works across both Bamboo and Cedar stacks
  • Removing incorrect and confusing metrics reported by Heroku or partner services like New Relic
  • Adding metrics that let customers determine queuing impact on application response times
  • Providing additional tools that developers can use to augment our latency and queuing metrics
  • Working to better support concurrent-request Rails apps on Cedar
  • The remainder of this blog post explains the technical details and history of our routing infrastructure, the intent behind the decisions we made along the way, the mistakes we made and what we think is the path forward.
0

精彩评论

暂无评论...
验证码 换一张
取 消