我的理解是,当我将文件上传到我的heroku实例时,它是一个同步请求,当请求完成后我将返回200,这意味着我的上传已经被回形针处理和存储。
我正在使用plupload进行串行上传(一次一个文件)。在Heroku我有3个dynos,我的应用程序没有响应,我得到超时试图使用该应用程序。我的上传应该只占用一个dyno,而所有文件都是上传的,因为它是串行完成的,而文件2没有启动,直到从文件1返回一个响应。
作为测试,我将我的dynos撞到了15并运行了上传。我再次看到帖子进入日志然后我开始看到回形针命令的输出(不记得它是识别还是转换)并且我开始获得超时。
我真的很想知道为什么会这样。我知道我'可以'直接上传到s3,但我目前的方法应该没问题。它是一个只供一个人使用的管理界面,最多它应该占用一个dyno,因为所有上传的文件都是连续发送的。
有什么想法吗?
答案 0 :(得分:1)
我一直在研究同样的问题几天。据我所知,问题在于,当通过heroku上传文件时,您的请求仍然受到30秒超时限制的约束。最重要的是,似乎发出给同一dyno(应用程序实例)的后续请求可能导致它产生响应时间并终止。例如,如果您向Web应用程序发出两个后续请求,每个请求需要15秒才能上载,您可以收到超时,这将强制dyno终止请求。这很可能是您收到超时错误的原因。如果在多个dynos上继续这样做,最终可能会导致应用程序崩溃,或者通常表现不佳。
我最终做的是使用jquery-file-upload。但是,如果要上载大文件(多个MB),则仍然会遇到错误,因为heroku仍在处理上传。特别是I used this technique完全绕过heroku并直接从客户端的浏览器上传到s3。我使用它来上传到临时目录,然后使用carrierwave“重新下载”文件,并通过将作业推送到Qu来处理后台的媒体和缩略图版本。现在,没有超时,但用户必须等待作业在后台处理。
另外需要注意的是,heroku dynos彼此独立运行,因此通过增加web dynos的数量,您可以为其他用户创建更多应用程序实例,但每个用户仍需要30秒超时和512Mb记忆无论你有多少dynos,你仍然会遇到同样的问题。 More dynos != better performance
答案 1 :(得分:0)
您可以使用Dropzonejs之类的东西来划分队列中的文件并单独发送。这样请求就不会超时。