压测环境搭建（硬件、软件、网络）归纳总结
压测环境搭得好，结果才可信。我在早期项目里吃过亏：随手拿一台开发机就跑压测，结果 CPU 被桌面环境吃掉一半，QPS 数据飘得像心电图。后来我学会了一件事——压测环境必须专用、可控、可复现。下面把硬件、软件、网络三个维度的要点串一遍，都是我自己踩过坑之后沉淀下来的做法。
硬件选型：别让资源先成为瓶颈
压测本质就是榨干被测系统的性能上限，所以硬件配置要“高于被测系统预期瓶颈的 1.5~2 倍”。我个人习惯先估算一下：目标 QPS 对应的 CPU 核数、内存用量、网卡吞吐，再反推服务器配置。
| 硬件维度 | 推荐配置 | 避坑点（我遇到的） |
|---|---|---|
| CPU | ≥8 核，主频 3.0GHz+ | 别用低功耗 CPU，频率波动会影响压测稳定性 |
| 内存 | ≥32GB | PKI 签名运算会吃缓冲，内存不足触发 swap 直接崩结果 |
| 磁盘 | NVMe SSD，≥500GB | 日志写到机械盘，压测时 IO 等待飙到 80%……后来换了 NVMe |
| 网卡 | 双口 10GbE，支持 RSS | 单千兆网卡跑 2000 TPS 就满了，白白浪费 CPU |
为什么要分开？你想想看，压测工具本身也要消耗 CPU 和内存，混在一起你测的到底是 SDK 的性能还是工具的性能？我曾经在同一台机器开 8 个 wrk 进程，结果 QPS 曲线是锯齿状——后来发现是客户端和服务器抢 CPU 时间片。
软件栈：版本、参数、监控一个都不能少
软件环境我习惯用 Docker 容器化，确保每次压测的 OS、依赖库、内核参数都完全相同。但被测的 PKI SDK 必须跑在宿主机或者直通模式，避免虚拟化层引入抖动。
操作系统
我用 Ubuntu 20.04 LTS 或 CentOS 7.9，内核统一选 5.x。别问我为什么不用最新版——稳定、内核参数调优文档多。曾经在 CentOS 8 上踩了 kernel 和 OpenSSL 1.1.1 的兼容坑，debug 了整整两天。
压测工具链
- wrk / wrk2：适合 HTTP 层面的 PKI 接口压测，Lua 脚本可控性好。
- JMeter：分布式压测场景，配合 CSV 参数化证书请求。
- 自研工具（Go）：我团队写了一个签名/验签压测器，直接调用 SDK 的 C 绑定，去掉网络层纯测 SDK 极限。
关键原则：压测工具的负载发生器要放在与被测服务器同网段甚至同一机架，RTT 控制在 0.1ms 以内。否则网络延迟会稀释 SDK 的真实处理能力。
SDK 编译与运行参数
记得用 Release 模式编译，打开 -O2 / -O3。我在项目中遇到过一次——Debug 版本跑了 3 小时压测，签名吞吐只有 Release 的 1/8。另外一定要关掉 ASLR 和 CPU 节能（cpupower frequency-set -g performance）。
# 我个人压测环境的标准操作
echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
ulimit -n 655350 # 文件句柄，OpenSSL 会开很多 socket监控工具矩阵
| 核心指标 | 监控工具 | 我的使用习惯 |
|---|---|---|
| CPU 使用率&频率 | htop / mpstat | 看最高核利用率，不是平均值 |
| 内存 & swap | free -h / smem | 压测前后对比，检查是否有泄漏 |
| 网络载荷 | nload / iftop | 确认网卡未打满，RTT 正常 |
| 磁盘 IO | iostat -x 1 | 注意 %util 和 svctm |
| SDK 内部指标 | SDK 自带性能计数器 | 比如签名耗时分布、缓存命中率 |
网络配置：被忽视的隐形瓶颈
网络环境是压测里最容易“及格但拉胯”的环节。说白了，大家都觉得 ping 通了就行，但实际流量大了之后，小包冲突、队列丢包、IRQ 亲和性都会跳出来。我经历过一次：千兆网卡跑满 600Mbps 时 CPU 软中断直接占 70%，结果 SDK 本身才用了 30%。
我的网络调优清单：
- 网卡多队列 + irqbalance 绑定：每个 CPU 核处理一个队列，避免中断全挤在 CPU0。
- MTU 改 9000（jumbo frame）：PKI 证书通常 1KB~2KB 每个请求，大 MTU 减少包数量，省 CPU。
- 关闭 offload 部分特性：比如 TCP 校验和 offload 虽然省 CPU，但在压测时可能掩盖异常，我建议关闭。
- 交换机端口流量整形：压测期间不允许其他业务流量经过同一端口。
- 禁用 IPv6 和防火墙：iptables / nftables 会增加 per-packet 开销，压测环境直接关掉。
一张图看懂压测环境全貌
下面这张 SVG 图把硬件、软件、网络三层串起来了，我画这个图的目的是：每次搭建新环境时，对着这张表逐项确认，避免遗漏。
环境验证清单：不能靠“感觉”
环境搭完不等于能用。我每次压测前会跑一遍验证脚本，确认所有软硬件参数符合预期。下面这个表格就是我的压测前自查表：
| 检查项 | 验证方式 | 合格标准 |
|---|---|---|
| CPU 频率锁定 | watch -n1 "cat /proc/cpuinfo | grep MHz" | 所有核频率稳定在标称值 |
| 内存无 swap | free -h | grep Swap | used=0B |
| 网卡速率 | ethtool eth0 | grep Speed | 10000Mb/s 或更高 |
| 网络延迟 | ping -c 100 server-ip | avg rtt < 0.2ms，无丢包 |
| SDK 版本 | strings libpki.so | grep VERSION | 与预期压测版本一致 |
| irqbalance 状态 | systemctl status irqbalance | active，且绑定策略生效 |
| 文件句柄限制 | ulimit -n | ≥655350 |
嗯，把这些都过了，压测环境才算真正就绪。我个人习惯把验证结果输出成一份报告贴在压测数据旁边，后续分析性能波动时可以直接回查环境状态。这招帮我省了不少“复现”的时间。