performance-testing

Performance Testing

References: Google "Site Reliability Engineering", Brendan Gregg "Systems Performance" USE Method, k6 Best Practices, JMeter Patterns.

Applicable Scenarios

Establish performance baseline before launch
SLA / SLO validation
Capacity planning (how many machines are enough)
Performance regression troubleshooting (vs previous version)
Load testing before major sales / high-concurrency events
Database / cache / queue capacity assessment

Core Principles

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

Test data close to production Everything measured with small data volumes is fake
What you measure is "system behavior", not peak numbers Long-duration runs + resource monitoring + bottleneck analysis
Baseline comparison matters more than absolute values "30% regression vs previous version" is more useful than "QPS 1000"
Performance issues left to production = incidents QA must find them in the test environment in advance


## 性能测试类型

### 负载测试（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、内存增长率

## 关键指标

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

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

Throughput

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

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

Error rate

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

Resource utilization (USE Method)

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

每种资源都问这三个问题

SLO template

模块：[订单创建 API]

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

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

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

Workflow

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 / 开发改进建议

Test data preparation

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

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

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

Tool comparison

Tool	Language	Advantages	Disadvantages
k6	JavaScript	Modern, CI-friendly, good reporting	Does not support GraphQL (directly)
JMeter	Java	Established, GUI, many plugins	Heavy, high performance overhead
Locust	Python	Easy to write scripts, distributed	Performance not as good as k6/Gatling
Gatling	Scala	High performance, beautiful reports	Learning curve
wrk	C	Extreme performance	Simple features
ab	C	Quick to get started	Single-threaded, few features

Recommendation:k6 as the primary + wrk as a quick baseline.

Common bottlenecks

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

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

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

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

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

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

Capacity planning formula

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

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

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

Quality self-check

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

Common pitfalls

Load testing without defining SLOs— after testing, you do not know whether it is good or bad
Test data too small— with 10 records, everything tests fast
Only looking at averages— P99 is what matters
Not monitoring resources— only looking at QPS, not CPU/Memory
Cold start not counted— the slow first request is ignored
Only testing the main path— edge scenarios bring down the system
Not doing soak testing— memory leaks only appear after 8 hours
Large differences between test environment and production— conclusions are unreliable
Third parties not mocked— overload third parties
No analysis after load testing— just throw a set of numbers to developers
Ignoring GC— P99 jitter is caused by GC
No buffer reserved— deploy at full load, and it collapses on a burst

Supporting templates

templates/perf-baseline-template.md — SLO + test scenarios + result data + bottleneck analysis + capacity conclusions + comparison with the previous version baseline

Collaboration with other skills

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

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