node.js - res.json() 和 res.end() 之间的性能差异

Question

我想使用 Node 和 Express 发送 JSON 响应。为此，我正在尝试比较 res.end 和 res.json 的性能。

版本 1:res.json

res.json(anObject);

版本 2:res.end

res.setHeader('Content-Type', 'application/json');
res.end(JSON.stringify(anObject));

运行一些基准测试，我可以看到第二个版本比第一个版本快了近 15%。如果我想发送 JSON 响应，是否有特殊原因必须使用 res.json？

Answer 1

是的，尽管开销很大，但使用 json 是非常可取的。

setHeader 和 end 来自 native http module .通过使用它们，您实际上绕过了 Express 的许多附加功能，因此在基准测试中出现了适度的减速。

但是，孤立的基准并不能说明全部情况。 json 实际上只是一种方便的方法，sets Content-Type 然后调用 send。 send是一个非常有用的功能，因为它:

• 支持 HEAD请求
• 设置合适的Content-Length头，保证响应不使用Transfer-Encoding: chunked，浪费带宽。
• 最重要的是，自动提供ETag支持，允许有条件的GETs。

最后一点是 json 最大的好处，也可能是 15% 差异的最大部分。 Express 计算 JSON 字符串的 CRC32 校验和并将其添加为 ETag header 。这允许浏览器对同一资源发出后续请求以发出条件 GET(If-None-Match header )，并且您的服务器将响应 304 Not如果 JSON 字符串相同，则修改，这意味着实际的 JSON 不需要再次通过网络发送。

这可以大大节省带宽(从而节省时间)。因为网络是一个比 CPU 大得多的瓶颈，所以这些节省几乎肯定会超过跳过 json() 所获得的相对较小的 CPU 节省。

---

最后，还有错误的问题。您的“版本 2”示例存在错误。

JSON 被字符串化为 UTF-8，Chrome(与规范相反)不默认将 application/json 响应作为 UTF-8 处理；你需要提供一个charset。这意味着非 ASCII 字符将在 Chrome 中被破坏。这个问题已经是discovered由 Express 用户和 Express sets适合您的标题。

这是小心过早/微优化的众多原因之一。您冒着引入错误的真正风险。