node.js response.write(data) 数据量小时需要很长时间

Question

我注意到以下代码在 node.js 中的性能有一个奇怪的行为。当content的大小为1.4KB时，请求的响应时间大约为16ms。但是，当 content 的大小仅为 988 字节时，请求的响应时间出奇地长得多，大约 200ms:

response.writeHead(200, {"Content-Type": "application/json"});
response.write(JSON.stringify(content, null, 0));
response.end();

这似乎并不直观。查看 Firebug 的 net 选项卡，增加/差异都来自接收(另一方面等待都是 16ms)。

我做了以下更改来修复它，以便两种情况的响应时间均为 16 毫秒:

response.writeHead(200, {"Content-Type": "application/json"});
response.end(JSON.stringify(content, null, 0));

我查看了 node.js doc但目前还没有找到相关资料。我猜这与缓冲有关，但是 node.js 可以在 write() 和 end() 之间抢占吗？

更新:

这是在 Linux 上的 v0.10.1 上测试的。

我试图窥视 source并确定了2条路径之间的区别。第一个版本有 2 个 Socket.write 调用。

writeHead(...)
write(chunk)
  chunk = Buffer.byteLength(chunk).toString(16) + CRLF + chunk + CRLF;
  ret = this._send(chunk);
    this._writeRaw(chunk);
      this.connection.write(chunk);
end()
  ret = this._send('0\r\n' + this._trailer + '\r\n'); // Last chunk.
    this._writeRaw(chunk);
      this.connection.write(chunk);

第二个好版本只有 1 个 Socket.write 调用:

writeHead(...)
end(chunk)
  var l = Buffer.byteLength(chunk).toString(16);
  ret = this.connection.write(this._header + l + CRLF +
                              chunk + '\r\n0\r\n' +
                              this._trailer + '\r\n', encoding);

仍然不确定是什么导致第一个版本不能很好地适应较小的响应大小。

Answer 1

简答:

您可以显式设置 Content-Length header 。它将响应时间从大约 200 毫秒减少到 20 毫秒。

var body = JSON.stringify(content, null, 0);
response.writeHead(200, {
    "Content-Type": "application/json",
    'Content-Length': body.length
});
response.write(content);
response.end();

事实:

经过几次实验，我发现if the content 足够小(在我的例子中，小于 1310 字节)对于单个 MTU继续，响应时间将在 200 毫秒左右。但是，对于任何大于该值的 content，响应时间大约为 20 毫秒。

然后我用wireshark抓取了服务器端的网络包。下面是一个典型的结果:

对于小的内容:

• [0000ms]response.write(content)
• [0200ms]收到客户端的ACK包
• [0201ms]response.end()

对于更大的内容:

• [0000ms]response.write(content)//发送第一个MTU
• [0001ms]发送第二个MTU
• [0070ms]收到客户端的ACK包
• [0071ms]response.end()

可能的解释:

如果未设置Content-Length header ，数据将以“Chunked”模式传输。在“Chunked”模式下，服务器和客户端都不知道数据的确切长度，因此客户端会等待一段时间(200ms)以查看是否有后续包。

然而，这个解释引发了另一个问题:为什么在更大的 content 情况下，客户端没有等待200ms(相反，它只等待了50ms左右)?