Node.js用Fastify搭建极简HTTP服务响应1ms是否属于偏高耗时？

结论 #

你的测试结果偏高主要是压测实现逻辑有缺陷，而非Fastify服务本身的性能问题。

具体问题分析 #

• 压测侧排队耗时被误算到服务端响应时间
  你写的压测脚本会一次性把所有并发请求全部塞进事件循环队列，Node.js单线程模型下，这些请求不可能同时发出去，前面的请求等待发送的排队时间也被你算进了响应耗时里，相当于把客户端的性能损耗也归到了服务端头上。
• 自行实现的压测逻辑缺少必要的优化
  你只做了1次握手预热，没有考虑Node.js的JIT编译开销：前几十次请求的执行会触发JIT编译，速度偏慢，需要足够的预热请求后再开始统计结果才准确。另外你没有配置http.Agent的maxSockets参数，虽然你开了keepAlive，但是高并发下的连接复用效率依旧会受影响。
• 同机运行的资源抢占问题
  压测客户端和Fastify服务跑在同一台机器上，两个Node.js进程会争抢CPU时间片，尤其是高并发场景下，调度延迟会被放大很多，这部分额外耗时也被算进了响应时间里。

优化建议 #

1. 优化Fastify服务配置 #

你可以简化路由写法，关闭不必要的内置功能进一步降低开销：

// server.js
const server = require('fastify')({ 
  keepAliveTimeout: 20000,
  disableRequestLogging: true, // 关闭请求日志记录
  exposeHeadRoutes: false // 不需要自动生成HEAD路由
})

// 直接返回响应体即可，不需要手动调用res.send，减少一层调用开销
server.get('/ping', async () => {
  return ''
})

server.listen(3000)

2. 更换专业压测工具 #

不要自行编写压测脚本，推荐直接用业界通用的Node.js生态压测工具autocannon，安装后执行以下命令即可完成100并发、10秒时长的压测：

npm i -g autocannon
autocannon -c 100 -d 10 http://localhost:3000/ping

正常配置下，空服务的平均响应时间在100并发场景下不会超过10ms，QPS可以达到3万以上。

3. 压测环境优化 #

如果要得到更准确的服务端性能数据，建议把压测客户端和服务端放在不同的机器上运行，或者给服务端进程绑定单独的CPU核心，避免资源抢占带来的误差。另外建议使用LTS版本的Node.js（比如v16、v18），你用的v15是非LTS的过渡版本，性能和稳定性都不如LTS版本。

内容的提问来源于stack exchange，提问作者Alexander