wrk 是比 ab 更现代、更适合高并发 HTTP 压测的工具，基于 epoll/kqueue 多路复用，支持 Lua 脚本实现登录态维持、动态 header 等复杂行为，且 QPS 更高、资源占用更低。
wrk 不是 Linux 自带工具，但它是比 ab 更现代、更真实、更适合高并发 HTTP 压测的选择——尤其当你需要模拟多连接、长连接、脚本化行为（比如带 Token 轮换、随机路径）时，ab 很快会力不从心。
为什么不用 ab 而选 wrk？
ab 是单线程事件模型，靠 fork 多进程模拟并发，实际压不出真实客户端行为；而 wrk 基于 epoll（Linux）或 kqueue（macOS），用少量线程 + 多路复用，轻松跑出数万 QPS，且内存占用低、CPU 利用率高。更重要的是：wrk 支持 Lua 脚本，能做登录态维持、动态 header、请求参数变异等 ab 根本做不到的事。
- 常见错误现象：
ab -c 1000 -n 10000 http://api.example.com/报socket: Too many open files或响应时间突然飙升——这不是服务端瓶颈，是ab自身 fd 耗尽 - 使用场景：压测网关、微服务接口、JWT 鉴权 API、需保持连接池的 gRPC-HTTP 转发层
- 性能影响：
wrk -t4 -c400 -d30s http://localhost:8080/health比同等参数的ab多压出 3–5 倍有效请求量
怎么装 wrk（别用源码编译）
大多数发行版没进默认仓库，但二进制包够用，别折腾 GCC 和 OpenSSL 依赖：
- Ubuntu/Debian：
sudo apt install -y curl && curl -L https://github.com/wg/wrk/releases/download/4.2.0/wrk_4.2.0_amd64.deb -o wrk.deb && sudo dpkg -i wrk.deb - CentOS/RHEL：
sudo yum install -y epel-release && sudo yum install -y wrk（EPEL 有打包，版本略旧但稳定） - 验证：
wrk --version输出类似wrk 4.2.0 [epoll] sizeof(struct kevent)=32即可
基础压测命令和关键参数含义
wrk 默认只发 GET，不带任何 header，这点和 ab 类似，但参数语义更直白：
-
-t是线程数（不是“并发用户”），一般设为 CPU 核数，如-t4 -
-c是总连接数（connection pool size），不是每线程连接数——-t4 -c400表示 4 个线程共维护 400 个 TCP 连接 -
-d是持续时间，单位秒；-s指定 Lua 脚本，-H添加 header，如-H "Authorization: Bearer xxx" - 容易踩的坑：
-c设太高（如 10000）但服务端net.core.somaxconn或ulimit -n没调，客户端自己先卡住；建议先ulimit -n 65535
示例：wrk -t4 -c200 -d10s -H "User-Agent: wrk-test" http://127.0.0.1:3000/api/v1/users
带登录态的真实压测怎么做？
纯 wrk -H 写死 Cookie 或 Token 只适用于静态鉴权，真实场景要先登录拿 token，再用 token 发业务请求——这必须用 Lua 脚本：
- 写一个
login.lua：用wrk.method = "POST"登录，解析响应 JSON 提取token，存到wrk.thread:set("token", token) - 再写
auth-get.lua：在init阶段从 thread 取 token，拼到 header 里；每次request()都动态生成新请求 - 执行：
wrk -t2 -c100 -d30s -s auth-get.lua http://api.example.com/ - 注意：Lua 脚本里不能 sleep、不能阻塞 IO；token 过期要自己加逻辑刷新，否则压测中途全 401
wrk 的真实门槛不在安装，而在理解「连接数」和「线程数」的分离设计，以及 Lua 脚本中 thread-local 状态管理。很多人卡在脚本里 token 没传进去、header 拼错、或忘了 wrk.headers["X-Header"] = value 的赋值语法——这些细节不试三次根本记不住。 
