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%.res.json如果我想发送JSON响应,是否有特殊原因需要使用？

Answer 1

是的,json尽管有开销,但非常希望使用.

setHeader并end来自原生的http模块.通过使用它们,您可以有效地绕过Express的附加功能,从而在基准测试中适度减速.

然而,孤立的基准并不能说明问题. json真的只是一个方便的方法设置的Content-Type,然后调用send. send是一个非常有用的功能,因为它:

• 支持HEAD请求
• 设置适当的Content-Length标头以确保响应不使用Transfer-Encoding: chunked,这会浪费带宽.
• 最重要的是,ETag自动提供支持,允许条件GETs.

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

这可以节省大量带宽(从而节省时间).因为网络是一个很大更大的瓶颈不是CPU,这些节省几乎肯定日食相对较小的CPU节省你会从跳绳获得json().

最后,还有bug的问题.您的"版本2"示例有一个错误.

JSON被字符串化为UTF-8,而Chrome(与规范相反)并不默认将application/json响应处理为UTF-8; 你需要提供一个charset.这意味着Chrome中会破坏非ASCII字符.Express用户已经发现此问题,Express会为您设置正确的标题.

这是注意过早/微观优化的众多原因之一.你冒着引入错误的风险.