压测环境搭建：硬件与软件环境准备、压测工具选型与环境隔离

压测环境搭建，说白了就是给性能测试搭台子。台子搭不好，后面的数据全是废的。我见过太多团队，工具选得花里胡哨，结果环境没隔离好，压出来的数据连自己都不信。嗯，咱们一步步来。

硬件环境准备：别让机器拖后腿

压测对硬件的要求，跟普通功能测试完全不是一个量级。你想想看，模拟几千上万的并发用户，CPU、内存、网络，哪一项短板都会让结果失真。

我个人习惯，压测机至少要有 4 核 CPU、8GB 内存起步。如果是做高并发场景（比如 5000+ QPS），建议 8 核 16GB 以上。磁盘方面，SSD 是必须的，日志写入频繁，机械盘很容易成为瓶颈。

资源项	最低配置	推荐配置	说明
CPU	4 核	8 核+	压测工具本身需要计算线程调度
内存	8 GB	16 GB+	大量虚拟用户会占用内存
磁盘	SSD 256 GB	SSD 512 GB+	日志和结果文件写入频繁
网络	千兆	万兆	避免网络成为瓶颈

软件环境准备：操作系统与运行时

操作系统层面，我建议用 Linux（CentOS 7+ 或 Ubuntu 20.04+）。Windows 当然也能跑，但资源开销大，稳定性也不如 Linux。

几个关键的系统调优点：

• 文件描述符限制：默认 1024 肯定不够。压测时每个虚拟用户可能占用一个 socket，上万并发就需要上万的文件描述符。我一般设到 65535 或更高。
• 端口范围：Linux 默认本地端口范围是 32768-60999，并发高时端口不够用。建议扩大到 1024-65535。
• TIME_WAIT 优化：短连接场景下，TIME_WAIT 会堆积。可以开启 net.ipv4.tcp_tw_reuse 和 net.ipv4.tcp_tw_recycle（注意：内核 4.12 之后移除了 recycle）。

# 系统调优示例（/etc/sysctl.conf）
fs.file-max = 1000000
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_tw_reuse = 1
net.core.somaxconn = 65535

压测工具选型：JMeter vs Locust vs Gatling

工具选型这块，我踩过不少坑。早期我用 JMeter，后来项目需要 Python 生态，试了 Locust，再后来接触 Gatling。三个工具各有千秋，没有银弹。

维度	JMeter	Locust	Gatling
语言	Java（GUI 配置）	Python（代码编写）	Scala/Java（DSL）
协议支持	HTTP、JDBC、MQ 等丰富插件	HTTP 为主，扩展需自定义	HTTP、WebSocket、JMS
分布式	原生支持（Master-Slave）	原生支持（Master-Worker）	需额外配置
报告	HTML 报告一般，需插件增强	Web 实时报告	HTML 报告非常精美
学习曲线	低（GUI 拖拽）	中（需 Python 基础）	中高（需 Scala/Java）
性能	中等（Java 虚拟机开销）	中等（Python GIL 限制）	高（基于 Akka 异步）

我的选型建议：

• 团队 Java 技术栈、需要丰富协议支持 → JMeter。插件生态最全，遇到问题社区资料多。
• 团队 Python 技术栈、需要快速编写复杂场景 → Locust。代码即配置，灵活度高。
• 追求高性能、需要高并发模拟、报告要漂亮 → Gatling。我记得有一次压测 10000 并发，Gatling 的资源消耗只有 JMeter 的一半。

环境隔离：别让压测污染生产

环境隔离是压测的底线。我见过有人直接在预发布环境压测，结果把预发布的数据库打挂了，连带影响了生产的数据同步。嗯，这种事出一次就够你喝一壶的。

环境隔离的几个层次：

• 网络隔离：压测环境独立网段，跟生产、预发布物理隔离或 VLAN 隔离。
• 数据隔离：使用独立的数据库实例，或者至少独立的 schema。压测数据不能跟真实数据混在一起。
• 服务隔离：被测服务单独部署，不要跟其他服务共享资源。我曾经遇到过，压测时把同一台机器上的日志服务挤挂了，排查了半天才发现是资源争抢。
• 监控隔离：压测环境的监控指标要跟生产分开，避免告警混淆。

数据准备：压测数据的质量决定结果的可信度

数据准备是压测里最容易被忽视的环节。很多人随便造几条数据就开始压，结果压出来的数据跟线上表现天差地别。

数据准备的核心要求：

• 数据量级匹配：线上有 1000 万用户，压测环境至少准备 100 万。数据量太少，数据库的索引、缓存、分页等行为跟线上完全不同。
• 数据分布模拟：热点数据、冷数据、重复数据的比例要跟线上一致。比如用户 ID 的分布，线上可能是 Zipf 分布，你造数据时用均匀分布，结果缓存命中率完全对不上。
• 参数化：不要所有请求都用同一个参数。JMeter 的 CSV Data Set Config、Locust 的队列、Gatling 的 feeders 都可以实现参数化。

# 数据准备示例（Python 脚本）
import random
import csv

# 模拟用户 ID 的 Zipf 分布
users = [f"user_{i}" for i in range(1000000)]
weights = [1.0 / (i+1) for i in range(1000000)]

with open('test_data.csv', 'w') as f:
    writer = csv.writer(f)
    for _ in range(10000):
        user_id = random.choices(users, weights=weights, k=1)[0]
        writer.writerow([user_id, random.randint(1, 100)])

知识体系总览

下面这张图，把压测环境搭建的核心脉络串起来了。你可以把它当作一个检查清单，每次搭建环境时对照着过一遍。

这张图把硬件、软件、工具、数据、环境隔离串在了一起。你搭建环境时，按这个脉络走，基本不会漏掉关键环节。