2. 测试环境搭建：硬件、软件与压测工具选型
环境搭建这事儿，说简单也简单，说复杂能让你折腾一整天。我见过太多团队，工具选得挺好，脚本写得也漂亮，结果一跑压测，数据全是乱的——问题就出在环境上。说白了，吞吐测试的结果，有一半是环境决定的。
这一章，我把硬件配置、软件调优、工具选型这三块拆开讲。每块都有我踩过的坑，你注意听。
2.1 硬件环境配置
硬件是地基。地基不稳，上面再漂亮的优化都是白搭。我个人习惯，先看 CPU，再看内存，最后看网络。
2.1.1 CPU：别让压测机成为瓶颈
很多人以为压测就是往目标服务器猛发请求，压测机随便搞台笔记本就行。错。我曾经有一次用 MacBook 压线上服务，结果压测机自己先 100% 了，数据全废。
CPU 选型，记住三个要点：
- 核心数要够：压测工具本身需要线程/协程来模拟并发用户。建议至少 8 核，16 核以上更稳。
- 主频别太低：2.5GHz 以上是底线。有些云主机是共享核，跑压测时会被邻居抢资源，慎用。
- 超线程关不关？：我个人建议关掉。超线程在压测场景下反而容易引入抖动，数据不稳定。
2.1.2 内存：够用就好，别贪多
内存这块其实没那么玄乎。压测工具本身占不了太多内存，但要注意两点：
- 压测机内存：8GB 起步，16GB 稳妥。如果压测脚本里用了大量参数化数据（比如 CSV 文件），内存要跟着涨。
- 目标服务器内存：这个要看你的业务场景。我遇到过有人用 4GB 内存跑 Redis 压测，结果还没到并发 1000 就开始 swap，数据完全没法看。
2.1.3 网络：最容易忽略的坑
网络配置，嗯，这里要重点说。我见过最离谱的一次，压测机和目标服务器跨了三个交换机，延迟 5ms，结果吞吐量死活上不去。后来一查，网络链路里有个千兆交换机在中间卡着。
网络配置清单：
| 参数 | 推荐值 | 说明 |
|---|---|---|
| 带宽 | ≥ 1Gbps | 压测机和目标服务器之间，万兆更好 |
| 延迟 | < 1ms | 同机房内网，跨机房就别想了 |
| 丢包率 | 0% | 有丢包，数据直接作废 |
| 网卡队列 | 多队列 + RSS | 避免单核处理网络中断 |
2.2 软件环境配置
硬件搞定了，接下来是软件。操作系统参数和中间件调优，这两块是重头戏。
2.2.1 操作系统参数调优
Linux 默认参数是为通用场景设计的，跑压测必须改。我每次搭环境，第一件事就是调内核参数。
核心参数清单：
# /etc/sysctl.conf 关键配置
# 最大文件句柄数
fs.file-max = 1000000
# 网络优化
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
net.core.netdev_max_backlog = 65535
# TIME_WAIT 复用
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15
# 端口范围
net.ipv4.ip_local_port_range = 1024 65535
# 立即生效
sysctl -p为什么调这些？
file-max：压测时每个连接都是一个文件句柄，默认 1024 根本不够用。somaxconn：TCP 全连接队列长度，调大能减少连接拒绝。tcp_tw_reuse：允许复用 TIME_WAIT 状态的端口，避免端口耗尽。
另外，ulimit 也要改：
# /etc/security/limits.conf
* soft nofile 1000000
* hard nofile 1000000
* soft nproc 65535
* hard nproc 65535我曾经有一次忘了改 ulimit，压测跑到一半，压测机报 "Too many open files"，整个测试白做。嗯，从那以后我每次搭环境都先跑一遍 ulimit -n 确认。
2.2.2 中间件调优
中间件调优，说白了就是让软件吃透硬件。不同中间件侧重点不一样，我挑几个常见的说。
Nginx 调优要点：
worker_processes：设为 CPU 核心数，别多也别少。worker_connections：单 worker 最大连接数，建议 65535。keepalive_timeout：长连接超时，压测场景建议 65s。gzip：压测时关掉，避免 CPU 被压缩吃掉。
Tomcat 调优要点：
maxThreads：最大线程数，建议 200-500，别超过 1000。acceptCount：等待队列长度，建议 65535。connectionTimeout：连接超时，压测场景建议 5000ms。
2.3 压测工具选型
工具选型，我见过有人纠结好几天。其实没那么复杂，看场景选就行。
| 工具 | 语言 | 并发模型 | 适合场景 | 学习成本 |
|---|---|---|---|---|
| JMeter | Java | 线程池 | HTTP/数据库/复杂业务流程 | 中等 |
| Locust | Python | 协程 (gevent) | Web 服务/自定义协议 | 低 |
| wrk | C | 事件驱动 (epoll) | 纯 HTTP 高并发压测 | 低 |
2.3.1 JMeter：大而全，但吃资源
JMeter 是我用得最多的工具。它的插件生态很丰富，能压 HTTP、JDBC、JMS 甚至 gRPC。但有个问题——它每个虚拟用户都是一个线程，压测机资源消耗大。
我个人习惯：
- 单机并发不超过 1000，超过就用分布式。
- GUI 模式只用来调试脚本，正式压测用 CLI 模式：
jmeter -n -t test.jmx -l result.jtl - 参数化数据用 CSV，别用函数助手，性能差很多。
2.3.2 Locust：Python 党的最爱
Locust 用协程模拟用户，单机能撑到几千并发。它的脚本就是 Python 代码，灵活度很高。我有个项目需要压测 WebSocket，JMeter 搞了半天没搞定，Locust 半小时就写完了。
不过要注意：
- Locust 的 Web UI 在压测时也会消耗资源，建议关掉。
- 协程模型下，如果业务代码里有阻塞操作（比如同步 IO），性能会暴跌。
2.3.3 wrk：轻量级，专为高并发而生
wrk 是用 C 写的，基于 epoll 事件驱动，单机轻松压到 10 万并发。它只支持 HTTP 协议，但胜在轻量、高效。
基本用法：
wrk -t12 -c400 -d30s http://target.com/api
# -t12: 12 个线程
# -c400: 400 个并发连接
# -d30s: 持续 30 秒选型建议：
- 纯 HTTP 高并发 → wrk
- 复杂业务流程、多协议 → JMeter
- 快速原型、自定义协议 → Locust
2.4 环境搭建知识体系
下面这张图，把本章的核心逻辑串起来了。你搭建环境时，按这个流程走，基本不会漏东西。
环境搭建这块，说白了就是「把变量控制住」。硬件、软件、工具，每个环节都标准化，出来的数据才有说服力。我见过太多人一上来就调 JVM 参数、改数据库配置，结果压测机本身就有问题——你想想看，这能测出什么来？