Node.js（Next.js）应用并发请求处理效率低下问题排查

大概率是应用代码中存在阻塞性同步逻辑或全局锁，而非PM2 fork模式导致的问题，具体分析如下：

为什么不是PM2 fork模式的问题？ #

PM2的fork模式只是启动单个Node.js进程，而Node.js的事件循环本身支持异步IO并发处理——只要代码是异步调用外部服务（比如本地Drupal API），单个进程完全可以同时处理多个请求，不会出现请求排队等待的情况。只有当代码中存在同步阻塞操作时，才会卡住事件循环，让后续请求必须等待前面的操作完成才能执行。

现象对应代码问题的特征 #

你观察到的「并发请求耗时是单请求的N倍、多个请求同时完成」的现象，完全符合事件循环被同步阻塞的表现：每个请求都要串行等待前面的阻塞逻辑执行完毕，相当于把并发请求变成了串行处理，耗时自然随请求数成倍增加。而你已经排除了Drupal的性能问题，所以瓶颈必然在Next.js应用内部。

验证与排查步骤 #

• 查看进程CPU使用率：用pm2 monit监控应用进程，如果并发请求时CPU没有跑满，反而请求排队，说明是事件循环被阻塞，而非CPU资源不足。
• 生成Node.js追踪日志：给应用启动参数添加--trace-event-categories v8,node.async_hooks,node.synchronous，生成追踪文件后分析哪些同步操作占用了大量时间。
• 临时切换PM2 cluster模式：修改ecosystem.config.js的mode为cluster，并设置instances: max，如果并发性能立刻提升，就可以确认是单进程内的阻塞逻辑导致的问题（cluster模式用多进程分摊请求，单个进程的阻塞不会影响其他进程）。

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