3、性能测试工具：iperf3、wrk、ab、sysbench、perf、火焰图
做性能优化，最怕的就是「我觉得这里慢」。你得拿数据说话。我这些年踩过的坑，十有八九都是因为没测准就开始改代码。所以这一章，我把压箱底的工具清单拿出来，一个一个说清楚。
3.1 iperf3：网络带宽的照妖镜
iperf3 是测网络吞吐量的首选。说白了，它就是两台机器之间互相扔数据包，看看能跑多快。
核心用法：
# 服务端（先启动）
iperf3 -s -p 5201
# 客户端（发起测试）
iperf3 -c 192.168.1.100 -p 5201 -t 30 -P 4参数解释：-t 30 表示测试30秒，-P 4 表示4个并发流。我个人习惯先跑单流，再跑多流，这样能快速判断瓶颈在单核还是多核。
我的经验： 有一次客户反馈多协议转换器吞吐量上不去，我上去用 iperf3 一测，发现双向流量时掉速严重。后来发现是网卡中断亲和性没配置好，两个方向的中断都挤在同一个CPU核心上。调整后性能直接翻倍。
3.2 wrk：HTTP压测的瑞士军刀
wrk 比 ab 更现代，支持 Lua 脚本，能模拟复杂的请求场景。我一般用它来测 REST API 的极限。
wrk -t12 -c400 -d30s --latency http://192.168.1.100:8080/api/v1/convert这个命令的意思是：12个线程，400个并发连接，持续30秒。加上 --latency 能看到延迟分布，这对判断性能抖动非常关键。
避坑指南： 我曾经用 wrk 测一个协议转换服务，发现 QPS 只有 5000，怎么调都上不去。后来才发现是 wrk 所在的客户端机器网卡先跑满了。记住，压测时一定要先确认客户端资源不是瓶颈。
3.3 ab：老牌工具，简单粗暴
Apache Bench（ab）虽然老，但胜在简单。适合快速验证，不适合复杂场景。
ab -n 100000 -c 100 http://192.168.1.100:8080/-n 是总请求数，-c 是并发数。ab 的输出里，我最关注的是 Requests per second 和 Time per request 这两行。
嗯，这里要注意：ab 不支持 HTTP/2，也不支持动态参数。如果你的服务用了 HTTP/2，老老实实用 wrk 或者 h2load。
3.4 sysbench：数据库与系统综合测试
sysbench 不只是测数据库的。它还能测 CPU、内存、文件 I/O。在多协议转换器里，我常用它来模拟数据处理的负载。
| 测试类型 | 命令示例 | 关注指标 |
|---|---|---|
| CPU 性能 | sysbench cpu --cpu-max-prime=20000 run |
总时间、每秒事件数 |
| 内存带宽 | sysbench memory --memory-block-size=1M --memory-total-size=10G run |
传输速度（MB/s） |
| 文件 I/O | sysbench fileio --file-test-mode=rndrw prepare && sysbench fileio --file-test-mode=rndrw run |
IOPS、延迟 |
实战技巧： 我在调优协议转换器的内存分配策略时，先用 sysbench 跑内存测试，发现默认的 glibc 分配器在多线程下锁竞争严重。换成 jemalloc 后，内存带宽提升了 30%。
3.5 perf：Linux性能剖析的终极武器
perf 是内核自带的性能分析工具。它能告诉你 CPU 到底在忙什么——是执行指令，还是等内存，还是锁等待。
# 采样30秒
perf record -g -p $(pidof converter) -- sleep 30
# 生成报告
perf report -g graph-g 表示记录调用栈，这样你才能看到热点函数是谁调用的。我见过太多人只看 perf top 就下结论，结果优化错了地方。
我的习惯： 先用 perf stat 看整体指标，比如 perf stat -e cycles,instructions,cache-misses,branch-misses -p $(pidof converter) -- sleep 10。如果 IPC（每周期指令数）低于 0.5，说明 CPU 大量时间在等待，这时候就该查缓存命中率或者锁竞争了。
3.6 火焰图：让性能瓶颈一目了然
火焰图是 Brendan Gregg 的杰作。它把 perf 的采样数据可视化，让你一眼看出哪个函数占用了最多的 CPU 时间。
生成火焰图的流程：
# 1. 用 perf 采集数据
perf record -F 99 -g -p $(pidof converter) -- sleep 30
# 2. 生成火焰图（需要 FlameGraph 工具）
perf script | ./stackcollapse-perf.pl | ./flamegraph.pl > converter.svg怎么看火焰图？
- 宽度：代表 CPU 占用时间，越宽越要关注
- 高度：代表调用栈深度，越高说明函数调用链越长
- 颜色：通常是随机的，没有特殊含义
避坑指南： 我曾经看到火焰图上有个很宽的「平顶」，以为是某个函数太慢。优化了半天没效果。后来才发现是采样频率太低，导致多个短函数被合并了。记住，-F 99 是常用采样频率，对大多数场景够用。
3.7 工具选型总结
这么多工具，什么时候用哪个？我列个速查表：
| 场景 | 推荐工具 | 一句话理由 |
|---|---|---|
| 测网络带宽 | iperf3 | 专业、精准、支持双向测试 |
| 测 HTTP 接口 | wrk | 支持 Lua 脚本，灵活度高 |
| 快速验证 | ab | 系统自带，开箱即用 |
| 测系统资源 | sysbench | CPU/内存/IO 全覆盖 |
| 定位 CPU 热点 | perf + 火焰图 | 可视化，定位精准 |
最后说一句：工具只是手段，关键是你要理解数据背后的含义。别光顾着跑分，多想想「为什么这个指标高/低」。你想想看，如果连瓶颈在哪都不知道，优化又从何谈起呢？