我已经找到了Event loop for large files?,但它主要是关于下载。我从那篇文章中得出的结论是,node.js可能已经足够下载了,但它是一个久经沙场的解决方案,“还没有崩溃”。
但是上传又如何呢?我们有大量的文件被上传。我们做基因组学,人类基因组数据集的大小高达200 in。据我所知,Nginx总是在将请求转发到后端之前缓冲完整的请求、头部和主体。我们同时处理三个上传时内存耗尽。
我们有一群小型的,“做一件事,做得很好”的服务器在我们的应用程序中运行,其中一个服务器处理基因组数据的上传(和内部格式的类型转换),另一个服务器提供socket.io处理,以保持客户对应用程序生态中正在进行的上传进度和其他事件的评估。其他人处理身份验证、客户数据处理和普通媒体服务。
如果我没看错node的http/https模块的代码,node.js将是处理这些问题的理想工具:它本机使用HTTP/1.1,因此websockets传递将起作用,并且它在处理HTTP头之后将(request, response)元组传递给处理程序函数,但保持在主体上,直到处理函数绑定request.on('data', ...)事件以排出主体缓冲区。
我们的服务有一个分段良好的、基于url的名称空间:"/import“、"/events”、"/users“、"/api”、"/media“等。用一个node.js应用程序替换Nginx来处理所有这些问题是困难的还是不合适的?还是有一些晦涩难懂的反向代理(Nginx、Pound和Varnish都有类似的限制)已经完成了我想要的一切?
发布于 2011-11-24 15:07:35
正如另一个答案所说,formidable是一个用于处理上传的非常可靠的库。默认情况下,它会缓冲到磁盘上,但如果需要,您可以覆盖该行为,并按原样处理数据。因此,如果你想编写自己的代理,node.js + formidable将是一种很好的方式,可以让上传内容在传入时流传输。
你也可以试试node-http-proxy,但不幸的是,我不确定它是如何缓冲的。你还应该考虑到它还没有像Nginx那样被使用过,所以我不确定我会在多大程度上信任它直接暴露在野外(这本身不是库的问题,但更多的是Node的问题)。
你看过Nginx的client_body_buffer_size指令了吗?似乎将其设置为较低的值可以解决内存问题。
发布于 2011-11-24 11:28:39
我不知道你在问什么(没有任何tl;dr!)但是你可以看看这些模块:formaline和formidable,这两个模块都是久经考验的,成熟和快速的,它们将文件写入临时文件夹,并且不会轻易导致内存耗尽。在内存管理方面,v8垃圾收集器是最好的。
至于http代理,还有一个模块,node-http-proxy,它也是经过强化的,并在开发中使用。我相信他们做到了,以确保人们没有任何理由使用Nginx作为反向代理。
至于扩展您的应用程序,以及在多台机器上使用多个进程,我建议使用hook.io。使用hook.io,您可以为应用程序的每个部分创建进程,并且每个进程都可以通过发出事件和侦听事件来相互通信。它还不是完全稳定的,但对于开始开发来说已经足够了。
https://stackoverflow.com/questions/8249154
复制相似问题