压测是接口上线前绕不开的环节，再优雅的代码如果扛不住流量也只是纸上谈兵。在Node.js生态里，wrk和autocannon是讨论度最高的两款压测工具，但很多人只是拿来跑一下命令，并不清楚它们在实现原理、性能表现和扩展能力上的本质差异，导致选型时全凭感觉。这篇文章就从原理到实战，把两款工具掰开揉碎对比一遍。
一、底层实现原理：多线程C模型与事件驱动的较量
wrk是一款用C语言编写的HTTP基准测试工具，它的核心架构是「少量线程 + 每个线程大量连接」。wrk内部使用操作系统线程来运行测试任务，通常只需要2到4个线程，每个线程可以持有成百上千个TCP连接，再配合epoll、kqueue这类多路复用机制处理网络事件，最后用LuaJIT提供脚本扩展能力。这种设计让wrk自身的资源消耗极低，单机就能打出非常高的压力，测试结果受工具本身的影响很小。
autocannon则完全不同，它是Node.js官方团队成员Matteo Collina参与维护的纯JavaScript压测工具，底层基于Node.js的事件循环和非阻塞I/O。autocannon可以以库的形式被Node.js代码直接调用，也可以通过命令行使用。由于跑在V8引擎上，它的CPU占用通常比wrk高，但这带来一个巨大优势：你可以用JavaScript编写任意复杂的测试逻辑，直接复用npm上海量的模块，比如用uuid生成动态参数、用jsonwebtoken签发带认证的请求。
简单总结一下原理层面的差异：wrk追求的是「工具本身足够轻，把资源留给被测服务」；autocannon追求的是「测试脚本足够灵活，用JS写什么都行」。这个定位差异直接决定了后面所有对比项的走向。
二、安装与基本使用对比
先看安装。wrk在Linux上需要源码编译，macOS可以通过Homebrew快速安装：
# Ubuntu/Debian 源码编译安装 sudo apt-get install build-essential libssl-dev git -y git clone https://github.com/wg/wrk.git cd wrk make # 把可执行文件移动到PATH目录 sudo mv wrk /usr/local/bin/ # macOS直接用Homebrew brew install wrk
autocannon的安装就简单得多，只要有Node.js环境，一条npm命令搞定：
npm install -g autocannon
使用层面，两款工具的基本压测命令都很直观。wrk的典型用法是指定线程数和连接数：
# 2个线程、1000个连接、持续30秒 wrk -t2 -c1000 -d30s --latency http://127.0.0.1:3000/api/users
autocannon的参数风格类似，-c表示并发连接数，-d表示持续时间：
# 1000个并发连接、持续30秒 autocannon -c 1000 -d 30 http://127.0.0.1:3000/api/users
值得注意的是，wrk的线程数不宜设置过大，一般设为CPU核心数即可，线程只负责管理连接，真正的并发由连接数决定。而autocannon没有线程的概念，它的并发模型完全依赖Node.js事件循环，理论上单进程就能维持数千连接，但在连接数极高时可能出现工具自身成为瓶颈的情况，后面实测部分会详细说明。
三、脚本扩展能力：Lua与JavaScript的差距
真实业务压测很少只打一个静态URL，通常需要动态参数、多接口串联、请求头签名等定制逻辑，这时脚本能力就成了选型的关键。
wrk通过LuaJIT暴露了几个生命周期钩子，最常用的是request函数和response函数。下面是一个给每个请求添加随机查询参数的Lua脚本：
-- random_query.lua
-- 每个请求前执行，动态修改请求
request = function()
local id = math.random(1, 100000)
local path = "/api/users?id=" .. id
return wrk.format("GET", path, {["Content-Type"] = "application/json"})
end
-- 响应回调，可用于统计特定状态码
response = function(status, headers, body)
if status ~= 200 then
-- 非预期状态码计数
requests_failed = (requests_failed or 0) + 1
end
end
done = function(summary)
print("失败请求数: " .. (requests_failed or 0))
endLua脚本虽然轻量，但表达能力有限，写复杂逻辑比较别扭，而且调试体验一般。autocannon的脚本则是标准JavaScript，配合Node.js模块几乎无所不能：
// bench.js 以库的形式调用autocannon
const autocannon = require('autocannon')
const instance = autocannon({
url: 'http://127.0.0.1:3000',
connections: 1000,
duration: 30,
setupClient(client) {
client.on('headers', (statusCode) => {
if (statusCode !== 200) {
console.error('非预期状态码:', statusCode)
}
})
},
requests: [
{
method: 'GET',
path: '/api/login'
},
{
// 用上一步拿到的token访问下一个接口
setupRequest(req, context) {
req.path = '/api/orders'
req.headers = { authorization: context.token }
return req
}
}
]
}, (err) => {
if (err) console.error(err)
process.exit(err ? 1 : 0)
})
// 支持Pipeline与自定义回调，可以在响应里解析token
instance.on('response', (client, statusCode, returnTime, headers, body) => {
// 解析登录响应，保存token供后续请求使用
})可以看到，autocannon能轻松实现「登录拿token再查订单」这种多接口串联的复杂场景，还能直接读取环境变量、连接数据库准备测试数据，这是wrk很难做到的。如果你的压测场景涉及业务链路，autocannon明显更适合；如果只是纯HTTP吞吐量测试，wrk的Lua脚本已经足够。
四、实测数据与结果解读
用一个简单的Express服务做被测对象（返回固定JSON，Node.js版本18，4核8G机器），分别用两款工具压测，得到的大致数据如下（具体数值因环境而异，仅供参考趋势）：
| 指标 | wrk (2线程/1000连接) | autocannon (1000连接) |
|---|---|---|
| QPS（请求/秒） | 约28000 | 约24000 |
| 平均延迟 | 约32ms | 约39ms |
| P99延迟 | 约65ms | 约88ms |
| 工具自身CPU占用 | 约80%（单核折算） | 约120%（跨核） |
数据能反映出几个规律：第一，在同样的并发压力下，wrk打出的QPS略高、延迟更低，因为C实现加LuaJIT的开销确实更小；第二，autocannon的CPU占用更高，当并发连接超过一定规模（比如5000以上）时，autocannon进程本身可能先于被测服务到达瓶颈，此时需要开多个autocannon进程分布式压测；第三，两款工具给出的P99数据可能存在差异，这与它们统计延迟的采样方式有关，对比不同工具的绝对数值意义不大，应重点关注同一工具下不同版本服务之间的相对变化。
另外提一个常见坑：用压测工具测试本机服务时，工具和服务会争抢同一台机器的CPU，得出的数据会系统性偏低。严谨的做法是把压测工具跑在另一台机器上，通过网络访问被测服务，并确认两者之间的网络带宽不会先成为瓶颈。
五、选型建议与总结
综合来看，两款工具的适用场景可以这样划分：
- 选wrk的场景：追求极限吞吐量数据、CI/CD流水线中的快速基准回归、目标环境没有Node.js运行时、只需要简单参数化而不涉及复杂业务链路。
- 选autocannon的场景：需要模拟真实业务流程（登录后操作）、压测脚本需要复用npm生态、希望以编程方式集成进Node.js测试框架（比如配合tap、jest做自动化性能测试）、需要HTML格式的可视化报告。
还有一个容易被忽略的用法：两者并不互斥。很多团队用wrk做日常的接口吞吐量巡检，快速确认服务没有性能退化；在版本迭代涉及业务逻辑变更时，再用autocannon编写贴近真实的链路级压测脚本，深入验证改动对整体链路的影响。工具是手段，数据是目的，理解每款工具的度量方式和自身开销，才能让压测结果真正反映服务的容量边界。
Node.js压测wrkautocannon修改时间：2026-09-07 17:10:51