测试环境搭建：硬件选型与系统调优
吞吐测试的结果靠不靠谱，很大程度上取决于你的测试环境。我见过太多团队，花大价钱买了压测工具，结果跑出来的数据根本没法看——说白了，环境没搭对。
这一章，咱们就聊聊怎么搭一个靠谱的测试环境。从硬件选型到系统调优，再到网络评估，每一步我都会把踩过的坑和经验分享出来。
硬件选型：别让机器拖了后腿
选硬件之前，先想清楚一件事：你要测的是谁？是 Web 服务器、数据库、还是消息队列？不同的被测系统，对硬件的要求天差地别。
CPU：核心数与频率的博弈
我个人习惯，先看被测系统的并发模型。如果是多线程架构（比如 Java 应用），核心数比频率重要。如果是计算密集型（比如加解密、编解码），频率才是关键。
| 场景 | 推荐配置 | 我的经验 |
|---|---|---|
| 高并发 Web 服务 | ≥ 16 核，2.5GHz+ | 我曾经用 8 核机器压测，CPU 先跑满了，结果根本不是被测系统的瓶颈 |
| 计算密集型任务 | ≥ 8 核，3.5GHz+ | 记得开启超线程，能多榨出 20%-30% 的性能 |
| IO 密集型任务 | ≥ 4 核，2.0GHz+ | CPU 不是瓶颈，但别太寒酸，至少 4 核起步 |
内存：够用就好，但别抠门
内存这块，我踩过最大的坑就是「以为够用」。有一次压测一个缓存服务，我估摸着 16GB 内存绰绰有余，结果跑到一半，系统开始疯狂 swap，吞吐量直接腰斩。
我的建议是：
- 压测机：至少 32GB。压测工具本身要消耗内存，尤其是要模拟大量并发用户时。
- 被测机：根据应用类型来。Java 应用至少给堆内存留 8GB，数据库至少 16GB。
- 预留余量：实际使用量不要超过物理内存的 70%。超过这个线，GC 和 swap 就开始捣乱了。
磁盘：IOPS 才是王道
很多人选磁盘只看容量，其实对于吞吐测试来说，IOPS（每秒读写次数）比容量重要得多。
我曾经用机械硬盘做压测，结果磁盘利用率才 30%，IO 等待时间已经飙到 500ms 了。换成 NVMe SSD 之后，同样场景下 IO 等待时间降到了 5ms 以内。
| 磁盘类型 | 典型 IOPS | 适用场景 |
|---|---|---|
| 机械硬盘 (SATA) | 100-200 | 日志存储、冷数据 |
| SATA SSD | 5,000-10,000 | 一般应用、测试环境 |
| NVMe SSD | 50,000-100,000+ | 高吞吐压测、数据库 |
操作系统参数调优：把默认配置扔掉
Linux 默认配置是为了兼容性，不是为高性能设计的。做吞吐测试前，必须调优。我每次搭建新环境，第一件事就是跑一遍调优脚本。
网络栈调优
网络是吞吐测试的生命线。以下几个参数，我几乎每次都会调：
# 增大 TCP 缓冲区
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# 启用 TCP 快速回收和复用
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
# 增大连接队列
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
# 关闭慢启动后重置
net.ipv4.tcp_slow_start_after_idle = 0为什么调这些？说白了，默认的 TCP 缓冲区太小，高并发下数据包会频繁丢包重传。我曾经在一个项目中，只调大了缓冲区，吞吐量就从 5000 req/s 涨到了 12000 req/s。
文件描述符限制
这个坑我踩过不止一次。压测跑到一半，突然报错 "Too many open files"。一查，默认的文件描述符限制只有 1024。
# 临时修改
ulimit -n 655350
# 永久修改（/etc/security/limits.conf）
* soft nofile 655350
* hard nofile 655350嗯，这里要注意：修改完要重新登录或者重启进程才能生效。我建议直接设成 655350，够用且安全。
内核调度与内存管理
还有几个参数，虽然不是必须的，但调了之后效果很明显：
- vm.swappiness = 10：减少 swap 倾向，尽量用物理内存。默认值 60 太高了。
- kernel.numa_balancing = 0：关闭 NUMA 自动平衡。在压测场景下，手动绑核比自动平衡更稳定。
- net.ipv4.tcp_fin_timeout = 15：缩短 FIN-WAIT-2 超时时间，加快连接回收。
网络带宽评估：别让网线成为瓶颈
网络带宽评估，很多人觉得简单——看看网卡速率就行了。其实没那么简单。
理论带宽 vs 实际带宽
千兆网卡的理论带宽是 1Gbps，但实际能跑多少？我测过，纯 TCP 传输大概能到 940Mbps。为什么到不了 1000？因为 TCP 头部、IP 头部、以太网帧头都要占开销。
更关键的是，吞吐测试的流量模式跟文件传输不一样。HTTP 请求通常是小包（几百字节到几 KB），小包场景下，带宽利用率会更低。
| 包大小 | 千兆网实际吞吐 | 万兆网实际吞吐 |
|---|---|---|
| 64 字节 | ~100 Mbps | ~1 Gbps |
| 512 字节 | ~400 Mbps | ~4 Gbps |
| 1500 字节 | ~940 Mbps | ~9.4 Gbps |
你想想看，如果你的被测系统处理一个请求只需要 1ms，但网络传输占了 5ms，那瓶颈就在网络上。
如何评估网络是否够用
我的做法分三步：
- 计算理论需求：预估峰值吞吐量 × 平均请求大小 = 所需带宽。比如 10000 req/s × 2KB = 20MB/s = 160Mbps。
- 实际打流测试：用 iperf3 在压测机和被测机之间跑一下，看看实际能跑多少。
- 留 30% 余量：理论需求 × 1.3 = 目标带宽。别把网卡跑满，跑满了延迟会急剧上升。
一张图看懂测试环境搭建
下面这张图，是我每次搭建环境时都会参考的流程。从硬件选型到系统调优，再到网络验证，每一步都不能跳过。
环境验证：别急着跑压测
环境搭好了，参数调完了，网络测过了。这时候别急着上压测脚本。先跑一轮基准测试，确认环境本身没问题。
我习惯用以下工具做快速验证：
- iperf3：验证网络带宽和延迟
- fio：验证磁盘 IOPS 和延迟
- stress：验证 CPU 和内存稳定性
- ab 或 wrk：跑一个简单的 HTTP 压测，确认链路通不通
环境搭建这块，说白了就是「慢工出细活」。硬件选型别图便宜，系统调优别偷懒，网络评估别想当然。每一步都扎实了，后面的瓶颈分析才有意义。