Node.js并行请求响应耗时随数量增加上升，该现象是否正常及原因？

结论 #

该现象属于正常情况，并非请求库的BUG，核心原因由运行时调度、客户端连接限制、资源竞争三类因素共同导致。

核心原因拆解 #

• 默认HTTP连接池并发限制：Node.js 原生http/https模块默认对同一域名的最大并发连接数为5，request、axios等常用请求库默认复用全局的HTTP Agent配置。当你发起的并行请求数超过5时，超出的请求会进入等待队列，直到已有连接空闲才能发起实际请求，这部分等待时间会直接计入你统计的总耗时，刚好匹配你观察到的5个请求开始出现明显耗时增长的现象。
• 事件循环调度开销：Node.js 基于单线程事件循环处理异步IO，你通过for循环一次性推入100个请求任务时，每个请求的 socket 分配、TCP 握手、数据收发、回调执行都需要在事件队列中排队等待调度。越晚推入的请求，排队等待调度的时间越长，最终统计的从请求初始化到收到响应的总耗时自然递增。
• 端侧资源竞争：即使是本地回环服务，同时处理多并发请求时也会出现资源竞争：服务端序列化300KB JSON的CPU开销、TCP缓冲区排队、网卡带宽抢占、甚至进程的CPU时间片分配都会随并发数上升导致单个请求的处理耗时增加。

验证方案 #

你可以通过以下调整验证上述逻辑：

1. 调大HTTP Agent的最大并发连接数，测试耗时增长是否明显缓解：

// 全局修改默认配置
http.globalAgent.maxSockets = 100;
https.globalAgent.maxSockets = 100;

// 或在request调用时单独指定agent
const customAgent = new http.Agent({ maxSockets: 100 });
request.get(url + id , {
    auth: { bearer: token },
    agent: customAgent
}, (err, res, body) => {
  // 回调逻辑
})

2. 拆分请求耗时的各阶段统计（TCP连接时间、TTFB、内容下载时间），会发现耗时增长主要来自请求等待连接调度的阶段，而非实际的网络传输或服务端处理时间。

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