第二章 压测环境搭建：从选型到监控，一步都不能少

说实话，压测环境搭建这件事，看着简单，坑却不少。我见过太多团队，压测结果不准，最后发现是环境本身出了问题。今天咱们就把这块掰开揉碎了讲清楚。

2.1 压测机器选型：别让机器拖了后腿

选压测机器，说白了就是选「施压源」。你想想看，如果施压源自己先扛不住了，那测出来的数据还有什么意义？

核心原则：压测机器的性能必须远高于被压服务。

我个人习惯按这个标准来选：

• CPU：至少 8 核以上，推荐 16 核。压测工具（比如 wrk、JMeter）本身会消耗 CPU，尤其是并发高的时候。
• 内存：16GB 起步。如果压测脚本复杂，或者要记录大量日志，32GB 更稳妥。
• 磁盘：SSD 是必须的。机械盘在大量日志写入时，会成为瓶颈。
• 网卡：千兆网卡是底线，万兆更佳。这个后面会细说。

2.2 网络带宽评估：别让网线成了瓶颈

网络带宽这事，经常被忽略。但你想啊，压测时数据包在网络上飞来飞去，带宽不够，延迟和丢包就来了。

怎么估算带宽需求？

一个简单的公式：

所需带宽 = 预期 QPS × 平均请求包大小 × 8

举个例子：

• 预期 QPS：10000
• 平均请求包大小：2KB
• 所需带宽 = 10000 × 2KB × 8 = 160Mbps

嗯，这里要注意：这只是单向的。如果响应包也大，还得加上响应带宽。我一般会留 50% 的余量。

2.3 被压服务部署：环境一致性是命门

被压服务的部署，核心就一句话：和生产环境保持一致。

为什么？因为不一致的环境会带来完全不同的性能表现。比如：

• 生产用 Linux，压测用 Windows？不行。
• 生产用 JDK 11，压测用 JDK 8？也不行。
• 生产是 4 核 8G，压测是 2 核 4G？更不行。

我个人习惯的做法是：

1. 容器化部署：用 Docker 或 K8s，保证环境完全一致。
2. 配置参数：JVM 参数、连接池大小、超时时间，全部和生产对齐。
3. 数据量：数据库里的数据量也要和生产接近。数据太少，索引效果不同，结果会偏乐观。

2.4 监控系统搭建：没有监控，压测就是盲人摸象

压测过程中，你必须知道系统在干什么。CPU 高不高？内存够不够？GC 频繁吗？这些信息，全靠监控。

我推荐用 Prometheus + Grafana 这套组合拳。开源、强大、社区活跃。

2.4.1 Prometheus：数据采集层

Prometheus 负责拉取指标数据。它的架构很简单：

• Exporter：暴露指标数据的代理程序。
• Prometheus Server：定时拉取并存储数据。
• Alertmanager：告警管理（可选）。

常用的 Exporter 有：

Exporter	监控对象
node_exporter	服务器基础指标（CPU、内存、磁盘、网络）
jmx_exporter	Java 应用（JVM 指标、GC、线程）
mysqld_exporter	MySQL 数据库
redis_exporter	Redis 缓存

部署命令也很简单：

# 启动 node_exporter
./node_exporter --web.listen-address=:9100

# 启动 Prometheus（配置文件 prometheus.yml 里添加 target）
./prometheus --config.file=prometheus.yml

2.4.2 Grafana：可视化层

Grafana 负责把 Prometheus 里的数据画成图表。我个人习惯的做法是：

• 先导入官方 Dashboard（比如 Node Exporter Full 模板 ID：1860）。
• 再根据压测需求，自定义几个关键面板。

压测时我必看的几个面板：

1. CPU 使用率：看有没有打满。
2. 内存使用率：看有没有内存泄漏。
3. 网络吞吐量：看带宽是否够用。
4. GC 次数和耗时：看 JVM 是否健康。
5. 请求延迟（P99、P95）：看响应时间是否达标。

2.5 本章知识体系：一张图看懂

下面这张 SVG 图，把压测环境搭建的核心逻辑串起来了。你可以把它当作检查清单来用。

这张图的核心逻辑是：压测机器、网络、被压服务三者是基础，监控系统是眼睛。缺了任何一个，压测结果都可能失真。

想要更多资料，联系可可