3、wrk工具入门：wrk安装、基本参数讲解、第一个压测脚本、结果解读
3.1 为什么选wrk？
做压测这么多年，我试过不少工具。ab太老，jmeter太重，locust要写Python。wrk呢？轻量、高效、单机就能压出很高的并发。
说白了，wrk就是一个基于C语言的高性能HTTP压测工具。它利用操作系统的事件模型（epoll、kqueue），用很少的线程就能模拟大量并发连接。我刚开始用它的时候，第一反应是——这玩意儿怎么这么快？
嗯，这里要注意：wrk只支持HTTP协议，不支持HTTPS。如果你要压HTTPS接口，得用它的增强版wrk2，或者用其他工具。这个坑我踩过，后面会讲。
3.2 wrk安装
安装wrk其实很简单。我习惯在Linux上跑压测，因为性能损耗最小。Mac也行，但Windows就别想了——wrk原生不支持Windows。
Linux（CentOS/Ubuntu）安装：
# Ubuntu/Debian
sudo apt-get install build-essential libssl-dev git -y
git clone https://github.com/wg/wrk.git
cd wrk
make
sudo cp wrk /usr/local/bin/
# CentOS/RHEL
sudo yum install gcc openssl-devel git -y
git clone https://github.com/wg/wrk.git
cd wrk
make
sudo cp wrk /usr/local/bin/
# MacOS
brew install wrk
安装完验证一下：
wrk --version
看到版本号就说明装好了。我记得第一次装的时候，卡在make那一步，后来发现是没装libssl-dev。所以如果你make报错，先检查依赖。
3.3 基本参数讲解
wrk的参数不多，但每个都很关键。我列个表，方便你对照着看。
| 参数 | 全称 | 说明 | 示例 |
|---|---|---|---|
| -t | threads | 线程数。一般设为CPU核心数的2倍左右 | -t4 |
| -c | connections | 并发连接数。模拟多少个客户端同时请求 | -c100 |
| -d | duration | 压测持续时间。支持s、m、h | -d30s |
| --latency | 延迟统计 | 输出详细的延迟分布数据 | --latency |
| -s | script | 加载Lua脚本，用于自定义请求 | -s script.lua |
| -H | header | 添加自定义请求头 | -H "User-Agent: wrk" |
| --timeout | 超时时间 | 每个请求的超时时间，默认2s | --timeout 5s |
你想想看，这些参数怎么搭配？我个人习惯是：先确定并发数，再根据CPU核数定线程数。比如4核机器压100并发，我会用-t4 -c100。
3.4 第一个压测脚本
来，我们写第一个压测命令。假设你要压一个本地服务：
wrk -t4 -c100 -d30s --latency http://localhost:8080/api/test
这条命令的意思是：用4个线程，模拟100个并发连接，持续压30秒，同时输出延迟分布数据。
如果你想压POST接口，或者需要带请求体，那就得用Lua脚本了。我写个最简单的例子：
-- post.lua
wrk.method = "POST"
wrk.body = '{"username":"test","password":"123456"}'
wrk.headers["Content-Type"] = "application/json"
然后这样调用：
wrk -t4 -c100 -d30s -s post.lua http://localhost:8080/api/login
嗯，这里要注意：Lua脚本里的body和headers，每次请求都会带上。如果你需要动态生成数据，那就得在脚本里写循环逻辑。这个后面章节会细讲。
3.5 结果解读
跑完压测，你会看到类似这样的输出：
Running 30s test @ http://localhost:8080/api/test
4 threads and 100 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 45.23ms 12.34ms 234.56ms 78.90%
Req/Sec 556.78 89.12 789.00 75.00%
Latency Distribution
50% 42.10ms
75% 51.20ms
90% 62.30ms
99% 98.70ms
66789 requests in 30.00s, 89.45MB read
Requests/sec: 2226.30
Transfer/sec: 2.98MB
我来一行行拆解给你看：
- Thread Stats：每个线程的统计。Latency是延迟，Req/Sec是每秒请求数。Avg是平均值，Stdev是标准差，Max是最大值。
- Latency Distribution：延迟分布。50%的请求在42.1ms内完成，99%在98.7ms内。这个数据很关键，能看出你的服务是不是有长尾延迟。
- 66789 requests in 30.00s：总请求数和总耗时。
- Requests/sec：吞吐量，也就是QPS。这里是2226.3。
- Transfer/sec：网络吞吐量，每秒传输的数据量。
我曾经遇到过一个问题：压测结果里Latency的Max值特别大，比如几秒钟。后来发现是服务端有GC停顿。所以你看结果的时候，别只看平均值，一定要看99%甚至99.9%的延迟。
3.6 核心知识体系
我把这一章的核心逻辑画了张图，方便你理解wrk的工作流程：
这张图展示了wrk的工作逻辑：用户输入参数后，wrk解析参数，然后创建线程池和连接池。每个线程负责维护一组连接，并发发送请求并接收响应。整个过程是异步非阻塞的，所以效率很高。
好了，这一章的内容就这些。安装、参数、脚本、结果解读，四个步骤走下来，你已经能用wrk做基本的压测了。下一章我们会深入Lua脚本，让wrk能做更复杂的压测场景。
想要更多资料，联系可可