3. 压测环境搭建：硬件配置、网络拓扑、监控工具部署

说实话，压测环境搭得好不好，直接决定你后面调参能不能拿到真数据。

我刚入行那会儿，拿一台笔记本就敢跑百万并发压测，结果数据全是假的。后来才明白——环境本身就是被测系统的一部分。你想想看，瓶颈到底是 SDK 本身的性能问题，还是网络抖了一下？这锅甩不干净。

3.1 硬件配置：参数不是越大越好，是够用且可控

我先给个常用标配，这是我在几个中型项目里验证过的组合：

我记得有一次压测一个图片处理 SDK，应用服务器只配了 4 核 8 G，结果压到一半系统直接 OOM。后来调成 16 核 64 G，同样的压测脚本跑了 3 小时都没崩。

3.2 网络拓扑：两个场景，两种搭法

我习惯把压测场景分成两类：标准测试和极限测试。拓扑不一样。

• 标准测试拓扑：压测机 → 千兆交换机 → 应用服务器。适合日常回归和参数调优。
• 极限测试拓扑：压测机 → 万兆直连 → 应用服务器。去掉交换机带来的抖动，专门压 SDK 的吞吐上限。

你可能会问：为什么不全都用万兆直连？因为成本。而且标准测试的场景更贴近真实用户环境——用户走的是公网，中间隔了无数跳。

3.3 监控工具部署：别等到出问题了才想起看数据

压测过程中，监控是眼睛。没有监控，你就是在盲打。

我一般会部署三层监控：

1. 系统级：CPU、内存、磁盘 I/O、网络吞吐量。用 Prometheus + node_exporter 搞定。
2. JVM/进程级：GC 频率、堆内存、线程数。用 JMX Exporter 或 Java Agent 抓。
3. 应用级：SDK 内部耗时、错误率、热点函数。自定义埋点推给 Prometheus。

下面是监控服务器上的典型部署命令：

# 安装 Prometheus（假设是 Linux x64）
wget https://github.com/prometheus/prometheus/releases/latest/download/prometheus-2.45.0.linux-amd64.tar.gz
tar xvf prometheus-*.tar.gz
cd prometheus-*

# 启动 Prometheus，指定配置文件
./prometheus --config.file=prometheus.yml &

# 安装 Grafana
wget https://dl.grafana.com/oss/release/grafana-9.5.2.linux-amd64.tar.gz
tar xvf grafana-*.tar.gz
cd grafana-*
./bin/grafana-server &

Prometheus 配置文件里需要添加目标端：

# prometheus.yml 片段
scrape_configs:
  - job_name: 'node'
    static_configs:
      - targets: ['192.168.1.10:9100']  # node_exporter 端口
  - job_name: 'sdk_app'
    static_configs:
      - targets: ['192.168.1.20:8080']  # SDK 暴露的指标接口

3.4 完整环境架构图

下面这张图可以帮你快速理解压测环境的整体拓扑和监控数据流：

3.5 部署顺序与验证清单

我踩过最大的坑就是顺序搞反了——先跑压测才发现监控没接上，数据丢了一堆。

建议按这个顺序来：

1. 先把监控服务器搭好，Prometheus + Grafana 启动并验证。
2. 在被测服务器上部署 node_exporter 和 JMX Exporter，确认指标能抓到。
3. 在被测服务器上启动 SDK 实例，验证应用级指标接口正常。
4. 配置网络拓扑，做一次 ping + iperf 联调。延迟 <1ms，吞吐达到预期。
5. 在压测机上安装压测工具，写一个最简单的请求，确认能连通 SDK。
6. 跑一次 1 分钟短压，观察监控面板数据是否正常更新。

嗯，环境准备好了。接下来你就可以放心地开始压测，然后针对参数慢慢调了。