Node.js不是文件上传（以及所有基于事件循环的语言）的好选择 - 是真的吗？

据说使用Node.js对于文件上传并不可取，因为它阻塞了IO循环直到完成，所以我试图流式上传许多并发文件，并且我发现Sails.js（包装express和node ）将第一，第二，第三...块分别上传到N上传器，然后再次回到第一个上传器以循环方式获取下一个块，结果是：所有文件上传几乎完全相同类似于上传一个大小等于并发上传文件的聚合大小的大文件。Node.js不是文件上传（以及所有基于事件循环的语言）的好选择 - 是真的吗？

我终于得出结论，高命中率的文件上传系统不应该由采用IO事件循环技术的语言来设计，而是每个连接上传的客户端都应该在服务器上有自己的线程来实现正确的不同上传之间的分离以及服务器内存大小和客户端数量之间的线性关系。

我在这里得出了正确的结论，还是我误解了一些东西？

来源

2016-01-19 securecurve

*据说使用Node.js不建议上传文件* - 你从哪里听到的？任何链接？ –

我之前阅读过，具有讽刺意味的是我找不到它，但我找到了另一种方式http://stackoverflow.com/questions/22981624/will-node-js-get-blocked-when-processing-large-文件上传，所以这意味着我错了这个 – securecurve

@AleksandrM，但我仍然是我的问题立场：当我同时上传文件时遇到缓慢我不使用基于线程的系统时，我仍然不明白 – securecurve

你的结论是

每个连接的上传客户端必须在服务器上有它自己的线程来实现不同的上传

之间的适当分离是不正确的，因为在每个线程消耗资源用于内存管理，线程切换等。因此，在具有无限线程的线程环境中构建命中率文件上传将不会扩展。在node.js中使用基于流的上传解决方案时，与其他语言/平台相比，应用程序的内存占用量和性能应该相当具有竞争力。

来源

2016-01-19 10:45:15 saintedlama

谢谢你的回答。我尝试了你的流式上传建议，并在问题中写下我的结论 – securecurve

'''结果是：所有文件上传几乎同时完成，类似于上传一个大小等于文件大小的大文件并发上传的文件。''' – securecurve

你的结论离不开事实。基于事件循环的并发对于文件上传等I/O任务非常高效（同时发生）。事件循环仅在代码运行时被阻止 - 事件回调，如连接准备就绪，还有更多数据可用等。在代码中，您只需执行非常快速的操作，例如说明您想要对数据执行什么操作，应该去哪里填充缓冲区和I/O传输由OS内核处理。在现代计算机上，您可以做类似60000（+/- 50000）的并发传输，同时保持代码正常运行。

来源

2016-01-19 12:05:08

这是否意味着node.js将文件上传到另一个线程，以使主线程自由接收新的请求？ – securecurve

如果我说的是正确的，是什么使它不同于Apache风格的上传（每个连接的线程） – securecurve

另外，你如何解释当我以基于线程的系统中没有经验的方式同时上传文件时遇到的速度慢 – securecurve

Node.js不是文件上传（以及所有基于事件循环的语言）的好选择 - 是真的吗？

回答

相关问题