性能测试笔记

性能测试：

• 所谓性能测试其实就是效率的测试。

目前市场主流的性能测试工具：

• JMeter：Apache 开源，基于 Java，功能全面（HTTP/Dubbo/数据库/消息队列等协议），支持 GUI 与命令行模式，适合接口级压测，生态成熟但单机并发能力有限。
• LoadRunner：Micro Focus 商业工具，支持协议最多、场景建模能力强，常用于大型企业级测试，成本高、学习曲线陡。
• Locust：基于 Python，使用协程（gevent）实现高并发，脚本即代码，易于扩展和集成 CI，适合需要编程化场景描述的团队。
• Gatling：基于 Scala/Akka 编写脚本，报告精美、资源占用低，适合 HTTP 场景的持续压测。
• k6：基于 Go 开发、使用 JavaScript 编写脚本，命令行驱动，云原生友好，与 Grafana/Prometheus 集成良好，适合 CI/CD 流水线中的性能回归。

所有的性能测试工具只是为了实现性能测试的一种手段和辅助的作用。

实质上的性能测试是在系统效率上的测试，我们需要关注的是系统整体运行的效率，是否存在有影响效率的性能问题。

对于单个核心接口进行性能测试，考虑它的并发最大能达到多少，是否满足性能指标。

常见的性能测试方法（测试类型）

• 基准测试（Benchmark）：单用户、少量并发下运行，获得系统的基准性能数据，作为后续对比的基线。
• 负载测试（Load Testing）：逐步增加并发/压力，验证系统在预期负载及边界负载下是否满足性能指标。
• 压力测试（Stress Testing）：超过系统预期负载持续加压，直到系统崩溃，找出系统的极限和崩溃点，观察崩溃后的恢复能力。
• 稳定性测试 / 耐久测试（Soak Testing）：在正常或较高负载下长时间运行（数小时~数天），发现内存泄漏、资源耗尽、句柄泄漏等慢性问题。
• 峰值测试 / 浪涌测试（Spike Testing）：瞬时突发大流量（如秒杀、大促），验证系统应对突发流量的能力。
• 容量测试（Capacity Testing）：确定系统可支持的最大用户量/数据量，为容量规划和扩容提供依据。
• 并发测试：多用户同时操作同一资源，验证是否存在死锁、数据竞争、事务异常等问题。
• 配置测试：调整软硬件配置（线程池、JVM 参数、连接池等），找到最优配置组合。

常用性能指标

• 响应时间（Response Time）：请求从发出到收到响应的耗时，重点关注 P90/P95/P99 分位数，而非平均值。
• 吞吐量（Throughput/TPS/QPS）：单位时间处理的事务数或请求数。
• 并发用户数（VU）：同时在线发起请求的用户数。
• 错误率：失败请求占比，压测中错误率飙升往往先于响应时间恶化。
• 资源利用率：CPU、内存、磁盘 IO、网络 IO 使用率。
• 饱和度：连接池、线程池、队列等关键资源的使用程度。
• 性能估算参考：并发数 = TPS × 平均响应时间（Little 定律）。

性能测试的流程：（和测试工具相关的步骤 2~3）

• 需求分析，分析系统的性能指标。

  • 明确核心业务场景、目标 TPS/QPS、响应时间要求、资源约束，梳理用户行为模型与业务配比。

• 准备环境，包含工具、场景等一系列性能测试相关需求

  • 尽量与生产环境等配（硬件、网络、数据量级），部署监控（Prometheus/Grafana、APM、日志），准备压测数据。

• 准备脚本，基于不同的性能场景完成测试准备。

  • 脚本需参数化（用户、数据）、关联（动态令牌）、添加事务与检查点、设置合理的思考时间与集合点。

• 执行脚本，获取数据。

  • 按照基准 → 负载 → 压力 → 稳定性的顺序逐步执行，压测机本身不能成为瓶颈（必要时分布式压测）。

• 判定指标是否满足要求。

  • 如果达标，还会继续进行进一步的性能测试。（测试系统的阈值、测试系统是否具有抗风险的能力，系统是否具有自动扩容的能力）
  • 如果不达标，进入到性能诊断

• 性能诊断

  • 自上而下分层排查：客户端/网络 → 接入层（Nginx、网关）→ 应用层（JVM/GC、线程池、慢代码、锁竞争）→ 中间件（缓存、MQ）→ 数据库（慢 SQL、索引、锁）。
  • 常用手段：监控大盘、火焰图（async-profiler）、Arthas、jstack/jmap、慢查询日志、APM 链路追踪（SkyWalking、Zipkin）。

• 提供优化建议

  • 输出测试报告：场景、数据、瓶颈定位、优化建议与优化前后的对比验证结果。