performance-testing

name	performance-testing
description	评估系统性能 / 容量 / 压测时使用。适用于上线前性能基线、SLA 验证、容量规划、性能退化排查。融合 Google SRE Workbook、Brendan Gregg USE Method、k6/JMeter 实践。

性能测试（Performance Testing）

参考来源：Google《Site Reliability Engineering》、Brendan Gregg《Systems Performance》USE Method、k6 Best Practices、JMeter Patterns。

适用场景

• 上线前建立性能基线
• SLA / SLO 验证
• 容量规划（多少机器够用）
• 性能退化排查（vs 上版本）
• 大促 / 高并发活动前压测
• 数据库 / 缓存 / 队列容量评估

核心原则

1. 先定义 SLO，再压测
   不知道目标的压测毫无意义

2. 测试数据接近生产
   小数据量测出来都是假的

3. 测的是"系统行为"，不是峰值数字
   长时间运行 + 资源监控 + 瓶颈分析

4. 基线对比比绝对值更重要
   "比上版本退化 30%" 比 "QPS 1000" 更有用

5. 性能问题留到生产 = 事故
   QA 必须在测试环境提前发现

性能测试类型

负载测试（Load Test）

• 目的：验证正常负载下系统稳定性
• 场景：QPS 100，持续 10 分钟
• 关注：响应时间、错误率

压力测试（Stress Test）

• 目的：找系统极限
• 场景：QPS 从 100 逐渐增加到崩溃
• 关注：拐点、极限 QPS、降级行为

浸泡测试（Soak / Endurance Test）

• 目的：长时间稳定性（内存泄漏 / 资源耗尽）
• 场景：QPS 100 持续 8 小时
• 关注：内存增长、连接池耗尽、GC

尖峰测试（Spike Test）

• 目的：突发流量恢复能力
• 场景：QPS 100 → 突增到 5000 → 回到 100
• 关注：恢复时间、是否雪崩

容量测试（Capacity Test）

• 目的：单实例吞吐 / 资源消耗
• 场景：固定 QPS，记录 CPU/Memory/IO
• 关注：每核 QPS、内存增长率

关键指标

响应时间

P50：50% 用户 < X ms（中位数）
P95：95% 用户 < X ms
P99：99% 用户 < X ms（关键指标）
Max：最大响应时间

注意：永远看 P99 不看平均值
平均值会被极快或极慢拉偏

吞吐量

QPS：每秒查询数（读）
TPS：每秒事务数（写）
RPS：每秒请求数

注意：QPS 不是越高越好
要在 SLO 范围内的 QPS

错误率

错误率 = 失败请求 / 总请求
SLO 通常 < 0.1% / 1%

资源利用率（USE Method）

Utilization：使用率（CPU / Memory / Disk）
Saturation：饱和度（队列长度 / 等待时间）
Errors：错误数（错误日志 / 异常）

每种资源都问这三个问题

SLO 模板

模块：[订单创建 API]

成功 SLO：
  - 99% 请求 P99 < 500ms
  - 错误率 < 0.5%
  - QPS >= 1000

容量 SLO：
  - 单实例支持 QPS >= 200
  - 内存使用 < 512MB
  - CPU 使用 < 70%

退化告警：
  - P99 > 800ms 持续 5 分钟
  - 错误率 > 1% 持续 1 分钟

工作流程

1. 定义 SLO
   - 与 PM、SRE 对齐目标
   ↓
2. 准备测试数据
   - 接近生产规模
   - 真实分布（80% 主路径 + 20% 边缘）
   ↓
3. 准备测试环境
   - 与生产同配置
   - 监控接好（Prometheus / DataDog）
   ↓
4. 编写测试脚本
   - k6 / JMeter / Locust / Gatling
   ↓
5. 执行
   - 先小规模冒烟
   - 再按场景执行
   ↓
6. 监控数据
   - QPS / 响应时间 / 错误率
   - CPU / Memory / IO / Network
   - 数据库 / 缓存 / 队列
   ↓
7. 分析瓶颈
   - 用 USE Method
   - 看慢查询日志
   - 看应用 trace
   ↓
8. 输出报告
   - SLO 是否达标
   - 瓶颈在哪
   - 容量结论
   - 与上版本对比
   ↓
9. 给 SRE / 开发改进建议

测试数据准备

规模：
  - 用户数：生产规模 80%~100%
  - 订单数：生产规模 80%~100%
  - 数据分布：模拟真实（新用户 / 活跃 / 沉睡）

数据生成：
  - 工具：generators / faker / 业务工具
  - 性能：百万级 < 1 小时
  - 隔离：独立 schema / 标记 _test_

冷启动 vs 热启动：
  - 冷启动：缓存空，第一次请求
  - 热启动：缓存预热后稳定
  - 都要测

工具对比

工具	语言	优势	劣势
k6	JavaScript	现代、CI 友好、报告好	不支持 GraphQL（直接）
JMeter	Java	老牌、GUI、插件多	重、性能开销大
Locust	Python	易写脚本、分布式	性能不如 k6/Gatling
Gatling	Scala	高性能、报告漂亮	学习曲线
wrk	C	极致性能	功能简单
ab	C	入门快速	单线程、功能少

推荐：k6 作为主力 + wrk 作为快速基线。

常见瓶颈

1. 数据库
   - 慢查询 / 锁冲突 / 连接池满
   - 解：索引 / 缓存 / 读写分离 / 分库分表

2. 缓存
   - 缓存穿透 / 击穿 / 雪崩
   - 解：布隆过滤器 / 热点预热 / 多级缓存

3. 应用
   - GC 频繁 / 内存泄漏 / 线程池满
   - 解：调 JVM / 异步化 / 解决泄漏

4. 网络
   - 带宽瓶颈 / TCP 连接耗尽
   - 解：长连接 / CDN / 增加带宽

5. 第三方
   - 调用慢 / 超时 / 限流
   - 解：异步 / 缓存 / 降级

6. 配置
   - 线程池 / 连接池 / 超时配置
   - 解：调参（先压测再调）

容量规划公式

所需实例数 = 总 QPS / 单实例 QPS × Buffer

示例：
  目标 QPS = 5000
  单实例 QPS = 200
  Buffer = 1.5（应对突发）
  
  实例数 = 5000 / 200 × 1.5 = 38 个

然后按 N+1 / N+2 容灾：
  → 实际部署 40 个

质量自检

□ SLO 已与 PM/SRE 对齐
□ 测试数据规模接近生产
□ 测试环境与生产同配置
□ 监控完整（应用 / 数据库 / 缓存 / 队列）
□ 测了主要场景（负载 / 压力 / 浸泡）
□ 浸泡测试 ≥ 1 小时
□ 尖峰测试做了
□ 瓶颈分析到根因
□ 与上版本基线对比
□ 容量结论给 SRE
□ 改进建议给开发

常见坑

1. 不定 SLO 就压测——压出来不知道好坏
2. 测试数据太小——10 条数据测出来都快
3. 只看平均值——P99 才是关键
4. 不监控资源——只看 QPS 不看 CPU/Memory
5. 冷启动不算——第一次请求慢被忽略
6. 只测主路径——边缘场景压垮系统
7. 不做浸泡测试——内存泄漏只在 8 小时后出现
8. 测试环境与生产差异大——结论不可信
9. 第三方不 Mock——压坏第三方
10. 压测后不分析——只丢一份数字给开发
11. 忽略 GC——P99 抖动就是 GC 引起
12. 不留 Buffer——满载部署，突发就崩

配套模板

• templates/perf-baseline-template.md — SLO + 测试场景 + 结果数据 + 瓶颈分析 + 容量结论 + 与上版本基线对比

与其他 skill 的协作

上游：
  test-strategy → 性能测试范围
  test-data-management → 大规模测试数据

下游：
  bug-reporting → 性能问题转 Bug
  test-report → 性能结论纳入报告
  quality-gate → SLO 作为放行条件
  SRE/运维工作流 → 监控告警建议
  DevOps 工作流 → 容量规划