上传的解剖结构

Question

我想知道上传中等大文件的普遍共识是什么。我有一个网络应用程序，并且每当用户上传一个文件（通常大于5mb）时，Web服务器往往会挂起，直到文件上传完成。

上面看起来很正常，因为单个上传可以占用一个HTTP请求处理程序。做web开发者考虑到这一点，并且：

一）对多个HTTP处理程序

b）利用一些其他的方法，通过使用AJAX或其他方式

听说已经克服这种支付Web应用程序有几个HTTP请求处理程序来处理这个问题是非常正常的，这会花费更多的代价。另一方面，如果成本问题，则有人建议直接通过Flash + AJAX直接上传到Web服务器或存储服务（如Amazon S3）。后一种方法需要一些脚本，并且有点麻烦。

我的第二个问题：

通过使用Ajax文件上传到服务器。这仍然占用一个完整的HTTP请求处理程序吗？即服务器是否挂起直到上传完成？

即使使用闪光灯，我仍然需要指定要上传的网址。该网址将是我的控制器上的一个操作。这意味着处理仍然发生在服务器端。这到目前为止是否正确？

我在想。另一方面，如果我使用其中一个上传脚本（plupload，uploadify，swfupload等）直接上传到Amazon S3，则在S3服务器上而不是本地Web服务器上处理该处理。根本不会挂上网络应用程序。我是否正确理解这一点？

想听听您的意见。

Answer 1

感谢迄今的回应。

不幸的是，我们的主机Heroku不支持非阻塞的服务器。我也尝试过基于Flash + JavaScript的上传器，如SWFUpload，Uploadify。提到的插件的一些变化工作，有些并没有。花了无数小时的试验和错误，但不喜欢代码被集成到我的Rails应用程序中。

最后，直接在link之后手动上传文件到S3。这也使得S3服务器的响应能够通知我们上传成功了，为我们提供了上传文件的路径，以便我们可以创建后台作业（通过redis + resque）来处理文件。

Answer 2

对于较大的上传，您应该使用非阻塞服务器，如Node.js，Pyhon上的Twisted， Perl上的AnyEvent或Ruby上的EventMachine。使用每个连接线程模型对于长时间运行的连接来说太昂贵了。

Node.js用户有这么多并发连接，他们实际上达到了他们的操作系统限制，同时还没有使用他们所有的资源 - 例如见this question被某人担心只有30 一千个同时连接，然后设法达到超过60000个连接在一个单一的服务器与4GB的RAM。

问题是，如果你担心你的连接阻塞你的服务器来提供新的请求，那么你不应该首先使用阻塞服务器。

Answer 3

我目前正在开发一个Web应用程序，它可以同时处理多个图像上传。我研究的范围很广，我发现的最佳选择是swfupload。这是非常容易实施和高度可定制的。用户可以从对话框中选择多个文件，将它们添加到队列中，并从浏览器获取实际进度反馈。所以这对用户来说并不是什么大不了的事情。

虽然，唉.....它使用闪存初始化对话框，但其他一切都用良好的旧javascript处理。

一个伟大的工作例子是carbonmade.com

Answer 4

未来如果您打算通过Rails直接上传到S3，请查看下面的示例项目。你会救自己很多很多的麻烦，它是不是很“凌乱” :)

示例项目使用Rails 3，Flash和基于MooTools的-FancyUploader直接上传到S3：https://github.com/iwasrobbed/Rails3-S3-Uploader-FancyUploader

示例项目使用Rails 3，闪存/ Silverlight的/ GoogleGears /的BrowserPlus和基于jQuery的Plupload直接上传到S3：https://github.com/iwasrobbed/Rails3-S3-Uploader-Plupload

顺便说一句，你可以使用像这样的博客文章介绍做后期处理回形针：

http://www.railstoolkit.com/posts/fancyupload-amazon-s3-uploader-with-paperclip