性能测试常用指标和工具

原创于 2025-11-26 08:44:08 发布 · 480 阅读

CC 4.0 BY-SA版权

文章标签：

性能测试（Performance Testing）
是一个广义概念，指通过模拟真实或预期的用户行为，评估系统在特定条件下的响应能力、稳定性、可扩展性和资源使用情况。其目标是验证系统是否满足性能需求（如响应时间 ≤ 2s），并为容量规划和优化提供依据。
负载测试（Load Testing）
是性能测试的一种，在预期正常或峰值负载下（如 1000 并发用户），观察系统表现。目的是验证系统能否在业务预期压力下稳定运行，关注指标如响应时间、错误率是否达标。
压力测试（Stress Testing）
是性能测试的另一种形式，逐步增加负载直至超过系统处理能力（如从 1000 并发加到 5000），观察系统在极限或异常条件下的行为。目的是找出系统的瓶颈点、崩溃阈值、恢复能力（如服务宕机后能否自愈）。

✅ 简单类比：

负载测试 = 满载一车人跑高速，看是否平稳；
压力测试 = 不断往车上塞人，直到车抛锚，看哪里先坏。

💡 实际项目中，常将“负载测试”作为性能测试的主要执行形式，“压力测试”用于专项探底。

指标类别	关键指标	说明	合理范围（示例）
用户感知	响应时间（RT）	用户操作到收到响应的时间	Web 页面 ≤ 2s，API ≤ 500ms
系统吞吐	TPS（Transactions Per Second）	每秒完成事务数	根据业务目标设定（如支付 ≥ 100 TPS）
	QPS（Queries Per Second）	每秒处理请求数	适用于无状态接口
	吞吐量（Throughput）	单位时间处理数据量（KB/s 或 req/s）	越高越好，需结合资源
并发能力	并发用户数（VU）	同时向系统发起请求的虚拟用户数	模拟真实业务高峰
稳定性	错误率（Error Rate）	失败请求占比	≤ 0.1%（关键交易应为 0%）
资源消耗	CPU 使用率	应用服务器 CPU 占用	≤ 75%（避免持续 100%）
	内存使用率	JVM 堆内存、物理内存	无持续增长（防内存泄漏）
	磁盘 I/O、网络带宽	磁盘读写、网卡流量	不成为瓶颈（如网卡未打满）

📌 黄金法则：TPS 上升 → RT 稳定 → 错误率低 → 资源合理，才是健康系统。

标准流程遵循 PDCA 循环，共 6 个阶段：

设计测试场景：
- 基准测试：单用户，测单接口基线
- 负载测试：阶梯加压（100 → 500 → 1000 VU）
- 稳定性测试：7×24 小时持续运行
- 压力测试：突破极限，观察崩溃点
准备测试数据：脱敏生产数据 + 参数化（用户 ID、商品 ID）

使用工具（如 JMeter）录制 HTTP 请求
关键动作：
- 添加参数化（CSV Data Set Config）
- 设置检查点（Response Assertion）
- 模拟思考时间（Timer）
- 处理关联（正则提取 token）
脚本验证：单用户调试通过

监控工具：
- 服务器：top, vmstat, nmon
- 应用：Prometheus + Grafana（JVM GC、线程池）
- 数据库：慢查询日志、show processlist
分析报告：
- 聚合报告：TPS、RT、错误率趋势图
- 响应时间分布：P90/P95/P99
- 资源使用曲线：CPU、内存、连接数

✅ 闭环：输出《性能测试报告》+《优化建议书》，推动改进落地。

工具	类型	优势	适用场景
Apache JMeter	开源	• 免费、社区强大 • 支持 HTTP/TCP/JDBC/MQ • 插件生态丰富（如 PerfMon）	Web/API/数据库压测，中小型企业首选
LoadRunner	商业	• 企业级支持 • 协议覆盖广（Citrix, SAP） • 强大的分析报表	金融、电信等大型传统企业
Gatling	开源	• 基于 Scala，高并发能力强 • DSL 脚本简洁 • 实时 HTML 报告	高并发 API 压测，DevOps 集成
Locust	开源	• Python 编写脚本，灵活 • 分布式易扩展 • Web UI 实时监控	开发团队自研压测平台
k6	开源	• 云原生友好 • 脚本即代码（TypeScript） • 与 CI/CD 深度集成	SaaS、微服务架构

🛠️ 个人推荐：

通用场景：JMeter（生态成熟）
高并发/云原生：k6 或 Gatling
复杂协议：LoadRunner（预算充足时）

这是典型的性能瓶颈现象，常见根因如下：

层级	可能原因	表现特征
应用层	• 线程池耗尽（Tomcat maxThreads=200） • 锁竞争（synchronized 过度使用） • GC 频繁（Full GC 停顿）	CPU 不高但 TPS 卡住，线程 BLOCKED
数据库层	• 慢 SQL / 缺失索引 • 行锁/表锁争用 • 连接池耗尽（maxActive=50）	DB CPU 高，`show processlist` 大量 Sleep 或 Locked
中间件层	• Redis 连接不足 • MQ 积压 • Nginx worker_connections 不足	中间件监控显示队列堆积、连接拒绝
系统层	• CPU 瓶颈（持续 100%） • 内存不足触发 Swap • 网络带宽打满（千兆网卡跑满）	`top` 显示 CPU idle=0%，`iftop` 显示网卡 940Mbps+
架构层	• 单点瓶颈（无集群） • 同步调用链过长	加机器无效，TPS 线性无法提升

🔍 排查口诀：
“先看资源，再看应用，最后查 DB” —— 从服务器资源 → 应用日志 → 数据库逐层下钻。

采用 “监控 → 日志 → 工具” 三层定位法：

工具：nmon, sar, Prometheus + Node Exporter
关键看：
- CPU：us（用户态）高 → 代码计算密集；sy（内核态）高 → 系统调用过多
- 内存：free 持续下降 → 内存泄漏
- I/O：await > 20ms → 磁盘慢

JVM 应用：
- Arthas（阿里开源）：
```
# 查看热点方法
profiler start; sleep 30; profiler stop

# 监控线程阻塞
thread -b  # 找死锁
```
- MAT（Memory Analyzer）：
  - 分析 heap dump，定位内存泄漏对象（如静态 Map 缓存未清理）
日志分析：
- 搜索 ERROR、Timeout、Deadlock
- 统计慢接口日志（如 grep "RT>" app.log | awk '{print $5}'）

MySQL：
- 开启慢查询日志：slow_query_log=ON
- EXPLAIN 分析执行计划，看是否走索引
- SHOW ENGINE INNODB STATUS 查锁等待
Redis：
- INFO memory 看内存碎片率
- SLOWLOG GET 查慢命令