2. 压测环境搭建：硬件环境规划、软件环境准备与网络隔离策略

说实话，压测环境搭建这块，我见过太多人翻车了。有人拿自己的笔记本当压测机，结果压到一半风扇狂转直接蓝屏。也有人把压测机和被测服务部署在同一台机器上，测出来的数据根本没法看。嗯，今天我就把这几年的经验好好捋一捋。

2.1 硬件环境规划

硬件规划，说白了就是回答三个问题：压测机用什么配置？被测服务器用什么配置？监控机要不要单独搞一台？

我个人习惯把硬件分成三层：

压测机（施压端）：负责生成并发请求
被测服务器（目标端）：运行你的业务系统
监控节点（观察端）：采集系统指标

这三层，物理上必须隔离。我在项目中遇到过有人把压测机和被测服务放在同一台物理机上，结果压测工具占用了大量CPU，被测服务的响应时间直接翻了三倍。你想想看，这数据还有参考价值吗？

2.1.1 压测机配置建议

场景	CPU	内存	磁盘	网络
轻量压测（< 1000 QPS）	4核	8GB	SSD 256GB	千兆
中等压测（1000-10000 QPS）	8核	16GB	SSD 512GB	万兆
高压压测（> 10000 QPS）	16核+	32GB+	NVMe 1TB	万兆+

我的小技巧： 压测机的CPU核心数最好与被测服务的线程池大小匹配。比如你的服务线程池是200，压测机至少要有8个物理核心，否则压测机自己先成了瓶颈。

2.1.2 被测服务器配置

这个其实取决于你的业务场景。但我有一条铁律：压测期间，被测服务器的资源利用率不要超过80%。为什么？因为超过80%后，系统的非线性效应会非常明显，响应时间会突然飙升。

我曾经帮一家电商公司做双11压测，他们的服务器CPU跑到85%时，RT从50ms直接跳到500ms。后来发现是JVM的GC线程和业务线程在抢CPU。嗯，这个坑我踩过，你们就别再踩了。

2.2 软件环境准备

软件环境这块，我建议统一用容器化部署。但考虑到很多团队还在用传统方式，我把三种主流语言的配置要点都列出来。

2.2.1 JDK 环境配置

如果你压测的是Java应用，JDK版本选择很关键。我个人推荐：

JDK 8：最稳定，适合老项目
JDK 11：LTS版本，性能有提升
JDK 17：最新LTS，ZGC加持

配置示例：

# 安装JDK 11
sudo apt-get install openjdk-11-jdk

# 设置环境变量
export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64
export PATH=$JAVA_HOME/bin:$PATH

# 验证
java -version
# 输出：openjdk version "11.0.18" 2023-01-17 LTS

注意： 压测机和被测服务器的JDK版本最好保持一致。我遇到过因为JDK小版本不同，导致TLS握手失败的情况，排查了一整天。

2.2.2 Python 环境配置

Python主要用于编写压测脚本和数据分析。我建议用虚拟环境隔离：

# 创建虚拟环境
python3 -m venv perftest_env

# 激活环境
source perftest_env/bin/activate

# 安装常用库
pip install requests aiohttp locust pandas matplotlib

这里有个坑：Python的GIL。如果你用多线程压测，实际并发能力会受限。我一般用多进程或者asyncio来绕过这个问题。

2.2.3 Node.js 环境配置

Node.js适合做高并发I/O场景的压测。配置要点：

# 使用nvm管理版本
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.3/install.sh | bash

# 安装Node 18 LTS
nvm install 18
nvm use 18

# 全局安装压测工具
npm install -g autocannon artillery

经验之谈： Node.js的event loop机制让它特别适合做长连接压测。我压测WebSocket服务时，首选Node.js + Artillery组合。

2.3 网络拓扑与隔离策略

网络拓扑设计，是压测环境搭建中最容易被忽视的一环。你想想看，如果压测流量经过了公司的办公网络，中间有防火墙、负载均衡器、VPN网关……这些设备都会引入额外的延迟和抖动。

2.3.1 推荐的网络拓扑

我画了一张图，展示标准的压测网络拓扑：

2.3.2 隔离策略详解

隔离策略我总结为「三隔离」：

网络隔离：压测流量走独立VLAN，不经过办公网络
资源隔离：压测机和被测服务使用不同的物理机或容器组
数据隔离：压测产生的数据写入独立数据库，不影响生产数据

我曾经踩过的一个大坑：

有一次压测时，压测流量经过了公司的VPN网关。结果VPN网关的带宽限制成了瓶颈，压测结果一直上不去。我花了三天排查代码，最后发现是网络拓扑的问题。从那以后，我坚持压测环境必须「裸连」——中间不要有任何网络设备。

2.3.3 网络配置检查清单

检查项	要求	验证方法
延迟	ping < 1ms	ping -c 100 目标IP
带宽	≥ 压测峰值流量 * 1.5	iperf3 测试
丢包率	0%	mtr 持续监控
防火墙规则	放行压测端口	telnet 或 nc 测试

特别提醒： 压测前一定要做一次网络基线测试。我习惯先跑10分钟的iperf，确认网络质量稳定后再开始压测。否则你测出来的抖动，到底是系统的问题还是网络的问题，根本说不清楚。

好了，环境搭建这块就聊到这儿。硬件选型、软件配置、网络隔离，这三件事做好了，压测就成功了一半。剩下的，就是怎么设计压测场景和解读结果了。

想要更多资料，联系可可

📚 课程目录

2. 压测环境搭建：硬件环境规划、软件环境准备与网络隔离策略

2.1 硬件环境规划

2.1.1 压测机配置建议

2.1.2 被测服务器配置

2.2 软件环境准备

2.2.1 JDK 环境配置

2.2.2 Python 环境配置

2.2.3 Node.js 环境配置

2.3 网络拓扑与隔离策略

2.3.1 推荐的网络拓扑

2.3.2 隔离策略详解

2.3.3 网络配置检查清单