性能压测与性能分析实战手册

性能测试不是简单地“把并发打上去”，而是通过可控的压力模型验证系统在不同负载下的响应能力、稳定性、资源消耗和容量边界。一次有效的性能测试，应该回答以下问题：

• 系统在目标并发下是否能稳定提供服务？
• 核心接口的平均响应时间、P95、P99 是否满足业务要求？
• 系统最大吞吐量是多少？拐点在哪里？
• 瓶颈出现在应用、数据库、缓存、网络、磁盘还是第三方服务？
• 当前资源配置能支撑多少用户量、订单量或请求量？
• 优化前后性能是否有可量化提升？

性能测试适用场景

请求与吞吐指标

响应时间指标

稳定性与资源指标

• 错误率：HTTP 5xx、业务失败码、超时、连接失败占比。
• CPU 使用率：长期高于 80% 需要关注，长期 90% 以上通常存在风险。
• 内存使用率：关注 RSS、Heap、缓存、Swap、OOM 风险。
• 磁盘 IO：关注 IOPS、吞吐、await、util、日志写入压力。
• 网络：关注带宽、连接数、TIME_WAIT、丢包、重传。
• 数据库：关注慢 SQL、锁等待、连接数、Buffer 命中率、主从延迟。
• 缓存：关注命中率、内存碎片、热 Key、大 Key、淘汰策略。

场景设计要素

3. 执行压测与复测

1. 先用小流量进行脚本冒烟，确认请求成功、断言正确、数据可用。
2. 再进行阶梯加压，例如 50、100、200、500、1000 并发。
3. 每个压力档位保持足够时间，至少覆盖缓存预热、GC、连接池稳定过程。
4. 记录每个档位的 QPS、RT、错误率和资源水位。
5. 出现大量错误、资源打满或业务异常时，及时停止并保留现场。
6. 优化后使用同样脚本、数据、环境和压力模型复测，避免结论失真。

k6 阶梯加压脚本

import http from "k6/http";
import { check, sleep } from "k6";

export const options = {
  stages: [
    { duration: "1m", target: 50 },
    { duration: "3m", target: 200 },
    { duration: "1m", target: 0 }
  ],
  thresholds: {
    http_req_failed: ["rate<0.01"],
    http_req_duration: ["p(95)<500"]
  }
};

export default function () {
  const res = http.get("https://example.com/api/products");

  check(res, {
    "status is 200": (r) => r.status === 200,
    "body not empty": (r) => r.body.length > 0
  });

  sleep(1);
}

k6 run load-test.js

登录态压测注意事项

登录态压测不要让所有虚拟用户共用同一个账号，否则会引入锁、风控、Session 覆盖、缓存热点等干扰。建议准备账号池，并让每个虚拟用户使用独立账号或独立 Token。

• 只校验 HTTP 200，不校验业务返回码，会掩盖真实失败。
• 所有请求使用同一条测试数据，会导致缓存命中率虚高。
• 没有设置超时时间，慢请求堆积后容易误判系统吞吐。
• 压测机性能不足时，瓶颈可能出现在客户端而不是服务端。
• 只压单接口，不压真实业务链路，结论通常偏乐观。

数据库压测关注点

• 慢 SQL 数量是否增加，索引是否命中，是否出现全表扫描。
• 连接池是否耗尽，是否存在连接泄漏。
• 锁等待、死锁、事务耗时是否异常。
• Buffer Pool 命中率是否下降，主从复制延迟是否扩大。
• 磁盘 IO 是否成为瓶颈。

Linux 常用监控命令

压测期间建议采集的数据

• 压测工具输出：QPS、P95、P99、错误率、请求总数。
• 应用监控：接口耗时、错误日志、线程池、连接池、GC。
• 主机监控：CPU、内存、磁盘 IO、网络连接。
• 数据库监控：慢 SQL、连接数、锁等待、缓存命中率。
• 缓存监控：命中率、内存使用、QPS、大 Key、热 Key。
• 链路追踪：慢 Span、下游调用耗时、外部依赖耗时。

Prometheus 常用观察指标

# HTTP 请求 QPS
sum(rate(http_requests_total[1m])) by (path)

# HTTP P95 响应时间
histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, path))

# HTTP 错误率
sum(rate(http_requests_total{status=~"5.."}[1m])) / sum(rate(http_requests_total[1m]))

# 容器 CPU 使用率
sum(rate(container_cpu_usage_seconds_total[1m])) by (pod)

# 容器内存使用
container_memory_working_set_bytes

瓶颈判断口诀

• QPS 上不去，CPU 打满：优先看应用计算、序列化、锁竞争、热点代码。
• QPS 上不去，CPU 不高：优先看 IO、数据库、外部依赖、连接池、锁等待。
• RT 升高，错误率不高：可能是排队、慢 SQL、GC、下游延迟。
• RT 升高，错误率升高：可能是资源耗尽、连接失败、超时、限流。
• 平均响应时间正常，P99 很高：重点排查长尾请求、锁、GC、网络抖动。
• 单机性能正常，集群性能不线性：关注负载均衡、共享资源、数据库瓶颈。

常见瓶颈与处理方向

压测曲线解读

• 理想阶段：并发增加，QPS 线性增加，RT 稳定。
• 临界阶段：QPS 增长变慢，RT 开始上升，资源接近高水位。
• 拐点阶段：QPS 不再增长，RT 快速上升，错误率开始增加。
• 崩溃阶段：大量超时或 5xx，服务不可用，资源耗尽或保护策略触发。

容量评估一般不要取系统极限值，而应取拐点之前的稳定区间，并预留安全水位。例如系统极限为 1000 QPS，建议线上容量按 600 到 700 QPS 规划，再配合限流、降级和扩容策略。

测试结论

环境信息

• 应用版本、Git Commit、配置文件版本。
• 服务器规格：CPU、内存、磁盘、网络。
• 部署方式：物理机、虚拟机、Docker、Kubernetes。
• 数据库与中间件版本、规格和参数。
• 压测机规格、网络位置、压测工具版本。

测试场景记录