我有一个在Ruby 2.1.1上运行Rails 4.1.5的heroku应用程序。
该应用程序涉及一些媒体处理，并涉及使用dropzone JS的javascript上传功能，用于在后续处理后台作业之前将照片保存在Amazon S3上的操作。
我有一个非常令人沮丧的问题。 Heroku路由器间歇性地 - 并且依赖于互联网连接的速度 - 以H15（空闲连接）状态杀死上传动作。我不相信连接已经空闲，因为使用相同的互联网连接，我可以将类似的文件上传到其他网站。
这与web dyno的超时无关，因为在路由器首先将其关闭的情况下，请求永远不会到达dyno。
这里可能会发生什么？
注意：我已经实现了这种CORS处理技术： http://www.tsheffler.com/blog/?p=428
日志：
[Timestamp] heroku [router]：at = error code = H15 desc =“Idle connection”method = POST path =“/ console / breeds / 57-YAMTALE / photos”host = [host] request_id = 634d7680-8b66 -4123-a4bc-fe78dc4e7b90 fwd =“[IP]”dyno = web.1 connect = 0ms service = 90232ms status = 503 bytes = 0
Procfile：
web：bundle exec rails server thin -p \ $ PORT -e \ $ RACK_ENV
可能相关的宝石：
宝石'瘦'
gem'carrierwave'
gem'carrierwave_backgrounder'
gem'rmagick'，：require =＆gt; 'RMagick'
gem'aws-sdk'
gem'chack-cors'，：require =＆gt; '机架/ CORS'
宝石'守护进程'
gem'exception_notification'
答案 0 :(得分：0)
您需要将大文件直接上传到S3（或同等版本），而不是通过您的Heroku应用程序。您可以将urn发布到您的应用程序（可能使用javascript），然后在后台处理/到S3。
不幸的是，这涉及到了。
Heroku在这里有一个（实际上相当不错的）指令： https://devcenter.heroku.com/articles/direct-to-s3-image-uploads-in-rails
<强>详情
如果Heroku路由器在30秒内没有收到第一个字节，则会超时。此后，它将跟踪一个55秒的滚动窗口，该窗口在向上或向下传输一个字节时被复位。 https://devcenter.heroku.com/articles/request-timeout
在您的情况下，我猜测您的上传有时需要超过30秒。虽然您正在将文件作为后台任务处理，但我猜测您在上传完成之前不会发回第一个字节。因此间歇性超时。
在上面引用的相同Heroku文档中：
许多Web应用程序允许用户上传文件。当这些文件 很大，或用户使用慢速互联网连接，上传 可能需要超过30秒。为此，我们直接推荐 上传到S3。
分块上传
我相信有一种替代方法可以使用HTTP分块上传来解决这个问题，其中可以在早期发送第一字节响应。 （这只适用于Cedar 1.1和更新版，它支持55秒滚动窗口）
事实上，分块方法应该比上面的直接S3方法更简单。我从来没有跟进过这个原因有几个原因：
1）Heroku没有提及它作为一种选择。
2）这会违背Heroku的一般建议：
最佳做法是让您的网络应用程序的响应时间低于＆gt; 500毫秒，这将释放更多请求的应用程序，并提供高＆gt;为访问者提供优质的用户体验。
3）它可能（根据我的理解，它会）对Heroku的负载平衡产生负面影响，这是原始的（或根据你的要求而破坏）。