测试环境规划：硬件选型与软件栈

环境规划这事儿，说白了就是给吞吐测试搭台子。台子搭不好，后面测出来的数据你都不敢信。我见过太多团队，上来就开测，结果发现瓶颈根本不在被测系统，而是环境本身——那才叫一个冤枉。

这一章，咱们把硬件选型、软件栈选择、环境隔离策略掰开揉碎了讲。你跟着我的思路走一遍，至少能避开七八成常见的坑。

硬件选型：CPU、内存、磁盘、网络

硬件选型没有标准答案，但有标准套路。我习惯按这个顺序来评估：CPU → 内存 → 磁盘 → 网络。为什么是这个顺序？因为吞吐测试的瓶颈通常就藏在这四个环节里，你得一个个排除。

CPU：核心数与主频的博弈

吞吐测试对CPU的要求，核心看两点：并发线程数和指令密集度。

• 核心数：压测工具本身需要线程来模拟用户。我个人习惯，压测机CPU核心数至少是被测服务核心数的2倍。举个例子，被测服务是8核，压测机至少16核起步。
• 主频：如果被测逻辑是计算密集型（比如加解密、编解码），主频比核心数更重要。我遇到过一项目，用低主频的E系列CPU压一个加密服务，结果压测机自己先跑满了，被测服务才用了30%。

内存：够用就好，但别省

内存选型有个简单公式：压测机内存 ≥ 被测服务内存 × 1.5。为什么？因为压测工具需要缓存连接状态、请求数据、响应数据。如果内存不够，操作系统会开始换页，吞吐量直接断崖式下跌。

我记得有一次，用一台16G内存的机器压一个8G内存的Java服务。压到一半，压测机开始疯狂swap，TPS从5000掉到800。查了半天，发现是内存不够——压测工具JVM堆才给了4G，但操作系统需要缓存网络连接和日志，加起来早超了。

磁盘：顺序读写与随机IO的取舍

磁盘选型，取决于你的测试场景：

场景	推荐磁盘类型	关键指标
日志写入密集型	NVMe SSD	顺序写入速度 ≥ 2000 MB/s
结果记录密集型	企业级SSD	随机IOPS ≥ 50000
普通压测场景	SATA SSD	顺序读写 ≥ 500 MB/s

我曾经用机械硬盘做压测，结果压测工具自己写日志就把磁盘IO打满了。TPS曲线跟心电图似的，根本没法看。从那以后，我压测机一律上SSD，哪怕是最便宜的SATA SSD也比机械盘强十倍。

网络：最容易忽略的瓶颈

网络选型，我只看三个数字：带宽、延迟、丢包率。

• 带宽：压测机网卡带宽必须 ≥ 被测服务网卡带宽。如果被测服务是万兆网卡，压测机至少也得万兆。否则，网络本身就成了瓶颈。
• 延迟：同机房内延迟应小于1ms。如果跨机房，延迟超过5ms，吞吐测试结果会严重失真。
• 丢包率：必须为0。哪怕0.1%的丢包，TCP重传也会让吞吐量下降30%以上。

软件栈选择：操作系统、中间件、数据库

软件栈的选择，核心原则是：与生产环境保持一致。但有些细节，生产环境不会告诉你，你得自己试出来。

操作系统：内核参数是隐藏的杀手

操作系统选型，我推荐Linux，具体发行版看团队熟悉程度。但不管选哪个，内核参数必须调优。

以下是我压测前必调的几个参数：

# 文件句柄限制
ulimit -n 655350

# TCP参数
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535

# 内存参数
vm.swappiness = 10

为什么调这些？说白了，压测时并发连接数会暴涨，操作系统默认参数根本扛不住。我遇到过一项目，没调文件句柄，压到一半压测工具报"Too many open files"，直接崩溃。调完之后，同样的脚本跑了12小时都没问题。

中间件：版本一致是底线

中间件选型，我只有一个要求：版本号必须与生产环境完全一致。大版本一致都不行，小版本也得一样。

举个例子，Nginx 1.18.0和1.20.0，HTTP/2的实现有差异，压测结果能差15%。你想想看，如果因为版本不一致导致测试结果不准，那整个压测就白做了。

数据库：连接池与隔离级别

数据库选型，重点看连接池配置和事务隔离级别。

• 连接池：压测时连接数会飙升，连接池太小会导致请求排队，太大又会耗尽数据库资源。我一般从max_connections = 200开始，逐步上调，直到找到拐点。
• 隔离级别：READ COMMITTED是大多数场景的默认选择。如果生产环境用了REPEATABLE READ，压测环境也必须一样。隔离级别不同，锁竞争的程度天差地别。

我记得有一次，压测一个MySQL服务，发现TPS始终上不去。查了半天，发现压测环境用的是READ UNCOMMITTED，生产环境是REPEATABLE READ。改回来之后，TPS直接翻倍——因为锁少了，并发上去了。

环境隔离策略：别让测试污染生产

环境隔离，说白了就是让测试环境的数据和流量，跟生产环境彻底分开。我见过最惨的案例，是压测时误操作写入了生产数据库，导致线上数据错乱。从那以后，我对环境隔离的要求近乎偏执。

网络隔离：VLAN与防火墙

网络隔离是最基础的。我建议：

• VLAN隔离：压测环境单独一个VLAN，跟生产环境、开发环境、办公网络完全隔开。
• 防火墙规则：压测环境只能访问被测服务，不能访问生产数据库、生产缓存、生产消息队列。

数据隔离：独立数据库与测试数据

数据隔离，我分三层：

1. 数据库实例隔离：压测环境使用独立的数据库实例，不能跟生产环境共用。
2. 数据内容隔离：测试数据必须打标，比如在用户ID前加"TEST_"前缀。这样即使误操作，也能快速识别和清理。
3. 数据量控制：压测数据量不能太大，否则清理起来很麻烦。我一般控制在生产数据量的10%以内。

资源隔离：容器化与资源限制

资源隔离，我推荐用Docker或Kubernetes。每个压测任务独立一个容器，限制CPU、内存、磁盘IO。

以下是我常用的Docker资源限制配置：

docker run \
  --cpus="4" \
  --memory="8g" \
  --memory-swap="8g" \
  --blkio-weight="500" \
  -d my-press-test:latest

为什么限制资源？因为如果不限制，一个压测任务可能把整个宿主机的资源吃光，影响其他任务。我遇到过一项目，两个压测任务同时跑，结果互相抢CPU，TPS曲线乱成一团。加上资源限制之后，两个任务各自稳定运行，数据也干净了。

本章知识体系

下面这张图，把本章的核心逻辑串起来了。你对照着看，思路会更清晰。

这张图从左到右，从上到下，把环境规划的三大块——硬件选型、软件栈选择、环境隔离策略——串成了一个完整的决策链路。你照着这个框架走，至少不会漏掉关键环节。