第三章：压测环境搭建——单机与分布式部署，网络与硬件瓶颈预判
说实话，很多团队做压测，上来就写脚本、调参数，结果跑出来的数据根本没法看。为什么？环境没搭对。我见过最夸张的一次，某团队用笔记本连公司Wi-Fi压测线上服务，结果网络抖动占了90%的延迟。嗯，这章我们就聊聊怎么把压测环境搭扎实。
3.1 单机压测环境：别小看这台机器
单机压测，说白了就是一台机器模拟用户发请求。听起来简单，但坑不少。
3.1.1 硬件选型要点
我个人习惯，压测机至少要有4核CPU、8GB内存。为什么？因为压测工具本身也要消耗资源。你想想看，如果压测机自己都卡了，测出来的数据能准吗？
| 硬件 | 最低配置 | 推荐配置 | 说明 |
|---|---|---|---|
| CPU | 4核 | 8核以上 | 压测工具多线程并发需要 |
| 内存 | 8GB | 16GB以上 | 存放请求数据、结果缓存 |
| 磁盘 | SSD 256GB | NVMe 512GB | 避免IO成为瓶颈 |
| 网络 | 千兆网卡 | 万兆网卡 | 防止网络成为短板 |
3.1.2 操作系统调优
单机压测，操作系统默认参数往往不够用。我建议你至少改这几个地方：
# 修改文件描述符限制
ulimit -n 65535
# 调整TCP参数
sysctl -w net.ipv4.tcp_tw_reuse=1
sysctl -w net.ipv4.tcp_fin_timeout=30
sysctl -w net.core.somaxconn=65535
# 关闭防火墙（测试环境）
systemctl stop firewalld为什么要改这些？因为压测时会产生大量短连接，默认参数根本扛不住。我记得有一次压测，没改参数前只能跑到2000并发，改了之后直接冲到8000。
3.2 分布式压测环境：单机不够用了
单机压测有个硬伤：一台机器能生成的并发有限。当你需要模拟上万甚至十万级并发时，就得用分布式压测。
3.2.1 架构设计
分布式压测的核心思路：一个控制节点 + 多个执行节点。控制节点负责下发任务、收集结果；执行节点负责实际发请求。
核心架构图：分布式压测系统
3.2.2 部署步骤
以JMeter为例，分布式部署其实不复杂：
- 控制节点配置：安装JMeter，修改jmeter.properties，设置server.rmi.ssl.disable=true
- 执行节点配置：每台机器安装JMeter，启动jmeter-server服务
- 网络打通：确保控制节点能访问执行节点的1099端口
- 启动测试：在控制节点上运行测试计划，勾选"远程启动所有节点"
3.3 网络瓶颈预判：别让网络背锅
很多性能问题，最后查出来是网络瓶颈。怎么提前发现？
3.3.1 带宽计算
先算一笔账：假设你的接口返回1KB数据，要压到10000 QPS，那需要的带宽是：
带宽 = 1KB × 10000 × 8 = 80Mbps这还只是下行。如果请求体也大，上行也要算。我曾经遇到一个项目，接口返回50KB的JSON，压到5000 QPS时千兆网卡直接打满。后来优化了接口，把数据压缩到5KB，问题才解决。
3.3.2 常见网络瓶颈
| 瓶颈类型 | 表现 | 排查方法 |
|---|---|---|
| 带宽不足 | 吞吐量上不去，延迟稳定 | sar -n DEV 查看网卡流量 |
| TCP连接数超限 | 大量Connection Refused | ss -s 查看连接状态 |
| DNS解析慢 | 首次请求延迟高 | dig +trace 测试解析时间 |
| 丢包重传 | 延迟抖动大，吞吐量波动 | netstat -s | grep retransmit |
3.4 硬件瓶颈预判：CPU、内存、磁盘
硬件瓶颈预判，说白了就是提前知道哪块会先扛不住。
3.4.1 CPU瓶颈
CPU瓶颈最明显的特征：CPU使用率接近100%，但吞吐量上不去。这时候你要看是用户态高还是内核态高。
- 用户态高：业务逻辑太复杂，考虑优化代码或加机器
- 内核态高：系统调用太频繁，比如大量上下文切换
我记得有一次压测，CPU用户态才30%，内核态却到了70%。查了半天，发现是线程数开太多，频繁切换导致。后来把线程池调小，问题解决。
3.4.2 内存瓶颈
内存瓶颈通常表现为：响应时间逐渐变长，最终OOM。怎么预判？
# 监控内存使用
free -h
# 查看进程内存
top -p PID
# 检查GC情况（Java应用）
jstat -gcutil PID 1000如果发现内存持续增长不下降，八成是内存泄漏。我建议压测前先跑个长时间稳定性测试，至少跑30分钟。
3.4.3 磁盘瓶颈
磁盘瓶颈最容易忽略。很多应用写日志、写数据库，磁盘IO会成为隐形杀手。
判断方法：iowait % 超过20%就要警惕了。可以用iostat看：
iostat -x 1
# 关注 %util 和 await 两个指标3.5 环境验证：压测前必做的检查清单
每次压测前，我都会过一遍这个清单：
- 网络连通性：ping、telnet确认端口通
- 资源监控：确保监控工具已部署（Prometheus、Grafana等）
- 基线数据：先跑一次小并发，记录基线
- 防火墙/安全组：确认没有限制
- 时间同步：所有机器NTP同步，否则日志时间对不上
嗯，环境搭好了，下一步就是写压测脚本了。不过那是下一章的事，先把环境搞扎实，后面才能跑出靠谱的数据。