性能测试

一、性能测试是什么

性能测试的核心目标是回答一个问题：系统能扛多大压力，瓶颈在哪里？

它不是简单地"压一下看看"，而是通过科学的方法，找到系统的能力边界和优化方向。

二、测试类型（按目的分）

怎么选择测试类型？

1
2
3
4
5

新系统上线前 → 基准测试 + 负载测试
大促活动前 → 压力测试 + 容量测试  
日常迭代   → 基准测试（回归）
核心系统   → 稳定性测试
秒杀场景   → 浪涌测试

三、测试场景（按业务分）

3.1 基础场景

3.2 进阶场景

3.3 混合场景设计示例

1
2
3
4
5
6
7

电商网站真实流量比例：
├── 首页浏览    40%
├── 商品搜索    25%
├── 商品详情    20%
├── 加入购物车   8%
├── 下单支付    5%
└── 用户登录    2%

混合场景的价值：单接口都没问题，混合起来可能有资源竞争。

四、性能指标体系

4.1 业务指标（用户视角）

响应时间的正确理解

1
2
3
4
5

平均 RT = 100ms  ← 看起来不错？
P90 RT = 150ms   ← 90% 的请求在 150ms 内
P99 RT = 800ms   ← 有 1% 的请求要 800ms！

结论：平均值会掩盖长尾问题，要看分位数

TPS vs QPS

1
2
3
4
5

TPS：一个事务可能包含多个请求（下单=查库存+扣款+创建订单）
QPS：纯粹的请求数量

接口压测一般说 QPS
业务压测一般说 TPS

4.2 系统资源指标（服务器视角）

CPU 指标详解

1
2
3
4
5
6
7

%user   - 用户态 CPU（应用代码）
%system - 内核态 CPU（系统调用）
%iowait - 等待 IO 的 CPU（磁盘慢）
%idle   - 空闲 CPU

iowait 高 → 瓶颈在磁盘，不是 CPU
user 高   → 瓶颈在应用代码

内存指标详解

1
2
3
4
5
6

used     - 已使用内存
free     - 完全空闲
buff/cache - 系统缓存（可回收）
available - 实际可用 = free + 可回收的 cache

看 available，不是 free

4.3 中间件指标（组件视角）

数据库（MySQL）

Redis

消息队列（Kafka/RabbitMQ）

4.4 JVM 指标（Java 应用）

五、常用工具

5.1 压测工具

5.2 监控工具

5.3 分析工具

六、性能测试流程

6.1 标准流程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

1. 需求分析
   ├── 测试目标是什么？（TPS 达到 1000？RT < 200ms？）
   ├── 测试哪些场景？
   └── 测试环境要求？

2. 环境准备
   ├── 测试环境搭建（尽量接近生产）
   ├── 监控部署（Prometheus + Grafana）
   ├── 数据准备（测试数据量级）
   └── 压测工具准备

3. 脚本开发
   ├── 接口脚本编写
   ├── 参数化配置
   ├── 关联处理
   └── 脚本调试验证

4. 执行测试
   ├── 基准测试（摸底）
   ├── 负载测试（验证目标）
   ├── 压力测试（找极限）
   └── 稳定性测试（长时间）

5. 结果分析
   ├── 指标是否达标
   ├── 瓶颈在哪里
   └── 优化建议

6. 测试报告
   ├── 测试结论
   ├── 数据图表
   └── 问题和建议

6.2 瓶颈定位思路

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

RT 变长 / TPS 上不去
    │
    ├─ CPU 高？
    │   ├─ user 高 → 代码问题（算法、死循环）
    │   └─ iowait 高 → 磁盘问题
    │
    ├─ 内存高？
    │   ├─ 持续上涨 → 内存泄漏
    │   └─ GC 频繁 → 堆内存不够
    │
    ├─ CPU/内存都不高？
    │   ├─ 数据库慢查询？
    │   ├─ 连接池打满？
    │   ├─ 锁竞争？
    │   └─ 外部依赖慢？
    │
    └─ 网络？
        ├─ 带宽打满
        └─ 连接数耗尽

七、Q&A

7.1 基础问题

Q：你们性能测试关注哪些指标？

三层：业务指标（RT、TPS、错误率）、系统资源（CPU、内存、IO、网络）、中间件指标（数据库、缓存）。重点是把指标放在同一时间轴上看，找到瓶颈。

Q：RT 看平均值还是 P99？

P99 更重要。平均值会被大量正常请求拉低，掩盖长尾问题。比如平均 100ms，但 P99 是 2s，说明有 1% 用户体验很差。

Q：TPS 和 QPS 的区别？

TPS 是事务，一个事务可能包含多个请求；QPS 是纯请求数。接口压测一般说 QPS，业务压测说 TPS。

7.2 场景问题

Q：你们预估的 QPS 是怎么得出的？

两种方法：1）看生产监控历史峰值；2）业务推算：日活 × 人均请求数 ÷ 集中时段秒数，再乘 2~3 倍余量。

Q：混合场景怎么设计？

分析生产日志或埋点数据，统计各接口调用比例，按比例配置并发。比如浏览 60%、搜索 25%、下单 5%。

Q：秒杀场景怎么测？

用集合点让请求同时发出，关注：1）限流是否生效；2）库存一致性；3）系统是否雪崩。

Q：稳定性测试发现过什么问题？

内存泄漏（内存持续上涨不释放）、连接泄漏（连接数持续增长）、GC 时间变长、RT 逐渐上涨。

7.3 定位问题

Q：TPS 上不去，怎么排查？

先看资源：CPU、内存、IO 哪个高。如果都不高，看数据库慢查询、连接池、锁竞争、外部依赖。

Q：CPU 高怎么定位？

看是 user 高还是 iowait 高。user 高用火焰图找热点代码；iowait 高说明磁盘是瓶颈。

Q：内存泄漏怎么定位？

多次 dump 内存快照，用 MAT 对比，看哪些对象持续增长。

八、实战检查清单

测试前

• 明确测试目标（TPS、RT、错误率要求）
• 测试环境配置记录（CPU、内存、带宽）
• 监控部署完成（能看到实时数据）
• 测试数据准备（数量级合理）
• 脚本调试通过（单次请求正常）

测试中

• 逐步加压，不要一上来就拉满
• 实时观察监控，发现异常及时记录
• 每轮测试记录：并发数、TPS、RT、错误率、资源使用
• 出现拐点时停下来分析

测试后

• 整理各轮数据，画趋势图
• 定位瓶颈点
• 输出测试报告
• 提出优化建议

九、附录：常用命令速查

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

# CPU
top                    # 整体情况
vmstat 1               # 每秒刷新
mpstat -P ALL 1        # 每个核心

# 内存
free -h                # 内存概况
top -o %MEM            # 按内存排序

# 磁盘
iostat -x 1            # IO 详情
iotop                  # IO 排行

# 网络
iftop                  # 带宽监控
netstat -ant | wc -l   # 连接数
ss -s                  # 连接统计

# 进程
ps aux --sort=-%cpu    # CPU 排行
ps aux --sort=-%mem    # 内存排行

# Java
jstat -gc <pid> 1000   # GC 监控
jstack <pid>           # 线程 dump
jmap -heap <pid>       # 堆内存概况

总结

性能测试的本质是：给系统施加压力，观察表现，找到瓶颈，指导优化。

记住这个思考框架：

1

目标 → 场景 → 指标 → 执行 → 分析 → 优化

不是为了压测而压测，而是为了回答业务问题：系统能不能扛住？扛不住的话问题在哪？