3. 压测环境搭建
环境搭建这事儿,说简单也简单,说复杂能让你折腾一整天。我见过太多团队,压测脚本写得漂漂亮亮,结果环境没搭好,跑出来的数据全是废的。说白了,压测环境就是你的实验台,台子不稳,实验结果谁敢信?
这一章,咱们就聊聊怎么把这个台子搭结实。我会从服务器、网络、数据库、中间件四个维度展开,最后再讲讲监控怎么部署。嗯,都是我在项目中踩过的坑,你直接拿去用就行。
3.1 服务器配置:别让硬件拖后腿
我个人习惯,在压测开始前先跑一轮 lscpu、free -h、df -h,把硬件底牌摸清楚。你想想看,如果压测机本身CPU都跑满了,那测出来的延迟到底是服务端的,还是压测机自己的?
核心检查清单:
- CPU:至少4核以上,建议8核。关闭CPU节能模式(
cpupower frequency-set -g performance) - 内存:压测机内存要够大,避免SWAP。我建议至少16GB,32GB更稳
- 磁盘:用SSD,别用机械盘。压测日志写得太快,机械盘IO会直接打满
- 网络:千兆网卡是底线,万兆更佳。检查
ethtool确认速率
内核参数这块,我踩过一个大坑。有一次压测,连接数一上去就报错,查了半天发现是net.ipv4.tcp_tw_reuse没开。嗯,这里直接给你一个我常用的优化脚本:
# 压测服务器内核优化(/etc/sysctl.conf)
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_keepalive_time = 300
net.ipv4.ip_local_port_range = 1024 65535
fs.file-max = 1000000
# 生效
sysctl -p
⚠️ 注意: 别在生产环境直接改这些参数!压测环境可以放开手脚,但生产环境要谨慎评估。
3.2 网络配置:延迟和丢包是隐形杀手
网络问题最隐蔽。我记得有一次压测,TPS死活上不去,查了服务器、数据库都没问题,最后发现是压测机和目标服务器之间隔了一层防火墙,延迟多了20ms。你想想看,20ms的延迟在1000并发下意味着什么?
网络配置我建议关注三点:
- 带宽:用
iperf3测一下实际带宽。别信网卡标称值,实际跑起来可能只有一半 - 延迟:
ping测试,RTT 稳定在 1ms 以内最好。超过 5ms 就要排查了 - 丢包:
mtr或traceroute看路径。丢包率超过 0.1% 就会明显影响压测结果
💡 小技巧: 我习惯在压测前先跑一轮 netstat -s,看看有没有大量重传或丢包。如果有,先修网络再压测,不然数据没法看。
3.3 数据库配置:连接池和慢查询是重点
数据库往往是压测的瓶颈。我见过太多人,压测一上来就把数据库连接池打满,然后报错说系统不行。其实呢?是连接池配小了。
以 MySQL 为例,我建议这样配置:
| 参数 | 推荐值 | 说明 |
|---|---|---|
| max_connections | 500~2000 | 根据服务器内存调整,别超过 2000 |
| innodb_buffer_pool_size | 物理内存的 70%~80% | InnoDB 缓存,越大越好 |
| innodb_log_file_size | 1GB~4GB | 写多的话设大点,减少日志切换 |
| query_cache_size | 0(关闭) | MySQL 8.0 已废弃,别开 |
另外,压测前一定要开慢查询日志:
SET GLOBAL slow_query_log = ON;
SET GLOBAL long_query_time = 1; -- 超过1秒的SQL记录下来
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';
避坑指南: 我曾经遇到过压测时数据库CPU飙升,查了半天发现是索引没建。压测前务必检查表结构,该建的索引一个都不能少。不然压测跑起来,慢查询能把数据库拖死。
3.4 中间件配置:线程池和队列是命门
中间件这块,我主要说 Redis 和 RabbitMQ,这两个是压测中最常见的。
Redis 配置要点:
maxmemory:设置为物理内存的 80%~90%,别设满maxclients:默认 10000,压测时建议调到 20000 以上timeout:设为 0,别让空闲连接被断开
RabbitMQ 配置要点:
- 连接数:默认 1024,压测时建议调到 5000 以上
- 队列长度:设置最大长度,防止内存溢出
- 消费者线程数:根据CPU核数调整,一般设为 2~4 倍核数
💡 个人经验: 中间件的超时设置要特别注意。我见过一个案例,压测时 Redis 超时设了 5 秒,结果一有延迟,请求全堵在等待上,TPS 直接归零。建议超时设短一点,比如 500ms,失败了就快速失败,别拖着。
3.5 监控准备:没有监控的压测就是盲打
监控这块,我强烈推荐 Prometheus + Grafana 的组合。轻量、灵活、社区生态好。你想想看,压测跑起来,你总得知道 CPU 用了多少、内存够不够、网络有没有丢包吧?
我一般会部署以下监控指标:
- 服务器层面:CPU 使用率、内存使用率、磁盘 IO、网络带宽
- 数据库层面:连接数、慢查询数、QPS、缓存命中率
- 中间件层面:连接数、队列长度、处理延迟、错误率
- 应用层面:TPS、响应时间、错误率、GC 情况
部署命令很简单,我直接给你一个快速启动脚本:
# 使用 Docker 部署 Prometheus + Grafana
docker run -d --name prometheus -p 9090:9090 prom/prometheus
docker run -d --name grafana -p 3000:3000 grafana/grafana
# 然后配置数据源,导入仪表盘模板
# 我常用的模板 ID:1860(Node Exporter)、7362(MySQL)
⚠️ 注意: 监控本身也会消耗资源。别在压测机上跑太重的监控,建议用单独的监控服务器。不然监控把压测机的资源吃了,测出来的数据就不准了。
好了,环境搭建这块就聊到这儿。配置到位了,监控跑起来了,下一步就可以开始真正的压测了。记住一句话:环境搭得好,压测数据才靠谱。别嫌麻烦,这一步省了,后面全是坑。
📌 本章小结:
- 服务器:检查硬件、调优内核参数
- 网络:测带宽、延迟、丢包
- 数据库:配连接池、开慢查询、建索引
- 中间件:调线程池、队列、超时
- 监控:Prometheus + Grafana,覆盖全链路