我的理解是，当我将文件上传到我的 heroku 实例时，它是一个同步请求，请求完成后我会得到 200，这意味着我的上传已被回形针处理和存储。
我正在使用 plupload 进行串行上传（一次一个文件）。在 Heroku 上，我有 3 个测功机，我的应用程序变得无响应，并且尝试使用该应用程序时出现超时。我的上传实际上应该最多只占用一个测功机，而所有文件都在上传，因为它是连续完成的，并且文件 2 直到文件 1 返回响应后才开始。
作为测试，我将我的测功机提高到 15 并运行上传。我再次看到帖子进入日志，然后我开始看到回形针命令的输出（不记得它是识别还是转换）并且我开始超时。
我真的很困惑为什么会这样。我知道我“可以”直接上传到 s3，但我目前的方法应该没问题。它是一个仅由一个人使用的管理界面，并且最多它应该占用一个测功机，因为所有上传的文件都是串行发送的。
有任何想法吗？
几天来我一直在解决同样的问题。据我了解，问题在于通过 heroku 上传文件时，您的请求仍受 30 秒超时限制的约束。最重要的是，似乎向同一个测功机（应用程序实例）发出的后续请求可能会导致它累积响应时间并终止。例如，如果您向 Web 应用程序发出两个后续请求，每个请求需要 15 秒上传，您可能会收到超时，这将迫使测功机终止请求。这很可能是您收到超时错误的原因。如果这种情况在多个测功机上继续存在，您最终可能会导致应用程序崩溃，或者只是性能普遍不佳。
我最终做的是使用jquery-file-upload。但是，如果您正在上传大文件（多个 MB），那么您仍然会遇到错误，因为 heroku 仍在处理上传。特别是我使用这种技术完全绕过heroku，直接从客户端的浏览器上传到s3。我使用它上传到临时目录，然后使用carrierwave通过将作业推送到Qu来“重新下载”文件并在后台处理媒体和缩略图版本。现在，没有超时，但用户必须等待作业在后台得到处理。
另外需要注意的是，heroku dyno 彼此独立运行，因此通过增加 web dyno 的数量，您正在为其他用户创建更多应用程序实例，但每个实例仍然受到 30 秒超时和 512Mb 内存的影响。无论您有多少测功机，您仍然会遇到相同的问题。更多测功机！=更好的性能。
您可以使用 Dropzonejs 之类的东西来将文件分成队列并分别发送。这样请求就不会超时。