我试图在加载大量内容时理解nodejs的限制。具体来说,我想知道流式传输对客户端的冗长响应是否会阻止。
我创建了一个非常简单的测试设置,其中节点只响应来自1GB http下载的流的每个请求。这是我的代码:
var http = require('http');
var fs = require('fs');
var iterator = 0;
http.createServer(function(req, res) {
console.log('req received ', iterator++);
var url = 'http://download.thinkbroadband.com/1GB.zip';
http.get(url, bigFile => {
res.writeHead(200, {
'content-type': 'application/zip',
'content-length': bigFile.headers['content-length'],
});
bigFile.pipe(res);
});
}).listen(8003);
所以我启动了这个节点服务器并在我的浏览器中使用几个选项卡命中了端点。有趣的是,后续回复不会立即使用console.log('request received ', iterator++);
代码进行记录。相反,在记录初始事件之前会有5到10秒的延迟。
这对我来说很奇怪,因为如果流式传输的http响应被阻止,那么它应该等到第一个请求完成后再接受第二个请求。如果流媒体没有阻止,那么我希望在他们被请求后立即看到所有请求。
有人可以解释一下吗?
我也很想听听有关表演的任何想法。 Node可能并不是真的为这类东西而建。下载速度真的受到多个请求的影响。
答案 0 :(得分:2)
经过一些研究后,我可以看到事件循环的不同阶段如何导致我看到的结果。节点guides解释了执行所有I / O事件的轮询阶段如何在需要时阻塞,并且它还具有最大堆栈,因此它不会完全阻塞主线程太久。
这可以解释我看到的有很多I / O事件的行为(即使我没有用21-23,0-6
监听它们的目录)可能会暂时阻止你的节点应用程序。在第一次请求之后我看到大约5到10秒的延迟,然后才能通过。
当然,还有其他一些方法可以改善性能,比如使用Cluster模块来使用机器上所有可用的处理器。但是,在一天结束时节点可能不是最好的解决方案。您可以从具有所需线程的传统Web服务器获得更好的性能。即使在使用了所有处理器之后,我只用节点推动了大约6%的CPU利用率。