📚 课程目录第3章 API性能基准测试

3. API 性能基准测试：压测工具选型与实战

基准测试是低延迟优化的起点。没有准确的基准，所有优化都只是猜测。本章聚焦压测工具选型、测试环境搭建、基准测试执行与报告分析，帮助你在发布后快速建立性能基线。

3.1 压测工具选型对比

主流压测工具各有侧重，选型需结合团队技术栈、协议支持、分布式能力和报告输出。下表从关键维度对比 wrk、JMeter 和 Locust。

维度	wrk	JMeter	Locust
语言	C（Lua 脚本扩展）	Java（GUI + XML）	Python（纯代码）
协议支持	HTTP/HTTPS	HTTP、JDBC、JMS、gRPC 等	HTTP（可扩展）
并发模型	epoll/kqueue 事件驱动	线程池	协程（gevent）
分布式	单机	支持（Master-Slave）	支持（Master-Worker）
延迟统计	内置（毫秒级）	聚合报告 + 插件	内置 + 可导出
学习成本	低	中	低
适用场景	快速基准、低延迟验证	复杂场景、多协议	持续集成、行为模拟

选型建议： 对于催收 API 的低延迟基准测试，推荐以 wrk 作为主要工具（轻量、高精度），以 Locust 作为行为模拟补充（用户登录、催收流程编排）。JMeter 更适合全链路压测和复杂断言场景。

3.2 测试环境搭建

环境一致性是基准测试有效性的前提。以下步骤确保压测环境与生产环境隔离且可重复。

独立压测机：使用与生产服务器同机房或同可用区的独立机器，避免网络抖动。
资源隔离：压测机 CPU/内存/网络带宽不与业务服务争抢。
系统调优：调整内核参数，提升并发连接能力。

# 压测机系统调优（/etc/sysctl.conf）
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
net.ipv4.ip_local_port_range = 1024 65535
fs.file-max = 1000000

# 立即生效
sysctl -p

wrk 安装：从源码编译，确保使用最新版本。

git clone https://github.com/wg/wrk.git
cd wrk
make
sudo cp wrk /usr/local/bin/

目标 API 准备：确认被测接口已上线，关闭非必要日志和调试模式，避免干扰延迟。

常见陷阱： 压测机与被测服务之间不要经过负载均衡器的限流层；如果必须经过，请提前确认限流阈值远高于预期压测 QPS。

3.3 基准测试执行

基准测试应分阶段执行，逐步增加并发，记录每个阶段的延迟分布。以下是一个典型的 wrk 执行命令模板。

# 单次基准测试：4 线程，100 连接，持续 60 秒
wrk -t4 -c100 -d60s --latency http://api.example.com/v1/催收/查询

# 输出示例
Running 60s test @ http://api.example.com/v1/催收/查询
  4 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    12.34ms    8.56ms 120.00ms   85.67%
    Req/Sec     2,345.6   312.4    3,012.0   75.00%
  Latency Distribution
     50%   10.21ms
     75%   15.78ms
     90%   22.45ms
     99%   45.67ms
  140,736 requests in 60.00s, 1.2GB read
Requests/sec:   2,345.60
Transfer/sec:   20.45MB

执行策略建议：

预热阶段：前 10 秒数据不计入统计，让连接池和 JIT 预热。
阶梯并发：从 10、50、100、200、500 并发逐步加压，观察延迟拐点。
重复次数：每个并发级别至少执行 3 次，取中位数。

3.4 报告分析与关键指标

基准测试报告的核心是延迟分布和吞吐量。以下 SVG 展示了从原始数据到优化决策的完整分析流程。

分析报告时应重点关注以下指标：

指标	含义	催收 API 目标值
P50 延迟	半数请求的响应时间	< 10ms
P99 延迟	99% 请求的响应时间	< 50ms
吞吐量 (QPS)	每秒完成的请求数	≥ 2000
错误率	非 2xx/3xx 响应占比	< 0.1%
延迟标准差	延迟波动程度	< 平均值的 50%

  实战案例： 某催收查询接口在 100 并发下 P99 延迟为 120ms，经分析发现数据库连接池过小（默认 10）。将连接池调整至 50 后，P99 降至 28ms，QPS 从 1200 提升至 3400。基准测试报告直接指导了连接池优化。

3.5 基准测试报告模板

每次基准测试应输出结构化报告，便于版本间对比。以下为推荐模板结构。

# 基准测试报告
## 测试信息
- 测试时间：2025-03-20 14:00
- 被测接口：/v1/催收/查询
- 压测工具：wrk 4.2.0
- 压测机配置：4C8G，同可用区

## 测试参数
- 线程数：4
- 并发连接数：100
- 持续时间：60s
- 预热时间：10s

## 结果摘要
- 总请求数：140,736
- 吞吐量：2,345.60 req/s
- 平均延迟：12.34ms
- P50：10.21ms
- P99：45.67ms
- 最大延迟：120.00ms
- 错误率：0.00%

## 延迟分布
- 50%：10.21ms
- 75%：15.78ms
- 90%：22.45ms
- 99%：45.67ms

## 资源监控
- CPU 使用率：65%
- 内存使用率：40%
- 网络入带宽：20.45MB/s

## 结论与建议
- 当前 P99 满足 50ms 目标，但最大延迟 120ms 需关注
- 建议优化数据库查询索引，减少慢查询

将报告纳入版本控制（如 Git），每次优化后重新执行基准测试，对比延迟变化趋势。只有持续追踪，才能确保低延迟优化不退化。