零基础学习性能测试第一章：核心性能指标-吞吐量QPS/TPS

零基础学习性能测试：第一章 - 核心性能指标：吞吐量(QPS/TPS)

本章核心目标：掌握吞吐量指标的本质意义、计算方法、应用场景，学会在实际工作中测量、分析和优化吞吐量性能。

一、吞吐量核心概念解析

1. 吞吐量定义与分类

吞吐量

QPS

TPS

每秒查询数

每秒事务数

指标	全称	定义	适用场景
QPS	Queries Per Second	系统每秒处理的请求数量	API接口、Web服务
TPS	Transactions Per Second	系统每秒完成的事务数量	支付系统、数据库操作

2. 核心区别与关系

维度	QPS	TPS	关系公式
关注点	请求处理能力	业务处理能力	1个事务 = N个请求
计量单位	请求/秒	业务事务/秒	TPS = QPS / 请求事务比
示例场景	每秒HTTP请求数	每秒支付订单数	支付事务=3请求：登录+支付+通知

实际案例：

• 电商下单：1个TPS = 5个QPS (加入购物车+结算+支付+扣库存+发通知)
• API服务：QPS = TPS (每个请求都是独立事务)

二、吞吐量关键价值与工作应用

1. 吞吐量的业务意义

35% 30% 20% 15% 吞吐量决定的核心业务能力 系统容量 用户体验 成本控制 商业价值

2. 实际工作场景应用

场景	吞吐量指标	决策依据
服务器采购决策	单机最大QPS	确定服务器配置和数量
云服务成本优化	实际运行QPS	动态调整云资源规模
大促容量规划	峰值TPS预测	提前扩容资源
系统架构优化	优化前后TPS对比	验证优化效果

工作模板：容量规划报告

双11容量规划报告

1. 业务目标：支撑50万笔/小时订单
2. TPS需求：140 TPS (50万÷3600秒)
3. 当前能力：100 TPS (压测结果)
4. 缺口分析：40 TPS容量不足
5. 解决方案：增加4台服务器（每台提升10 TPS）

三、吞吐量测试实战指南

1. 测试工具选择

工具	适用场景	吞吐量测试能力
JMeter	API/Web服务	支持QPS/TPS实时监控
LoadRunner	企业级复杂系统	完善的事务定义功能
wrk	高性能HTTP压测	轻量级高并发测试
k6	云原生测试	强大的结果分析功能

2. JMeter吞吐量测试全流程

用户 JMeter 服务器 1. 创建线程组（模拟并发用户） 2. 定义事务控制器 3. 发送HTTP请求 4. 接收响应 5. 聚合结果计算QPS/TPS 6. 生成测试报告 用户 JMeter 服务器

实操步骤：

1. 添加线程组：设置并发用户数（1000线程）
2. 添加事务控制器：标记业务事务
3. 添加HTTP请求：配置API参数
4. 添加聚合报告监听器
5. 运行测试并查看结果：

   Samples: 10000 (总请求数)
   Average: 50ms (平均响应时间)
   Throughput: 500/sec (QPS)
   Transactions: 200/sec (TPS)
   

3. 关键配置参数

参数	推荐值	说明
线程数	模拟实际并发用户	逐步增加找到瓶颈点
加速时间(Ramp-up)	10-30秒	避免瞬时压力冲击
循环次数	永久循环	持续测试稳定性
超时时间	5000ms	防止阻塞线程

四、吞吐量瓶颈分析与优化

1. 瓶颈定位四步法

2. 常见瓶颈及解决方案

瓶颈类型	特征	优化方案	优化效果
CPU瓶颈	CPU使用率>80%	优化算法/增加CPU核心	提升30-50% TPS
数据库IO	磁盘等待>20ms	增加索引/读写分离/SSD	提升2-5倍TPS
线程阻塞	线程池活跃线程=最大值	增大线程池/异步处理	提升100%+吞吐量
网络延迟	网络传输时间>100ms	CDN加速/专线接入	减少30-70%响应时间

3. 优化案例：电商系统吞吐量提升

1. 初始状态：

   • TPS：120
   • 响应时间：800ms(P95)

2. 瓶颈定位：

   • 数据库CPU使用率90%
   • SQL查询时间>500ms

3. 优化措施：

   • 添加商品查询索引
   • 引入Redis缓存热销商品
   • 分库分表用户订单数据

4. 优化结果：

   • TPS：350 (提升191%)
   • 响应时间：150ms(P95)

五、工作应用模板与工具

1. 吞吐量测试报告模板

系统吞吐量测试报告

测试目标
验证用户登录接口能否支撑1000 QPS

测试环境

• 服务器：4核8G云服务器
• 网络：1Gbps带宽
• 测试工具：JMeter 5.4.1

测试结果

并发用户数	QPS	平均响应时间	错误率
500	420	320ms	0%
1000	780	480ms	0.2%
1500	850	1200ms	5.3%

结论与建议

1. 系统最大安全QPS为780（1000并发）
2. 1500并发时响应时间陡增，需优化：
   • 增加Redis缓存会话信息
   • 数据库连接池从50调至100

2. 吞吐量监控看板(Grafana)

{
  "panels": [
    {
      "type": "graph",
      "title": "实时QPS",
      "targets": [{
        "expr": "sum(rate(http_requests_total[1m]))",
        "legend": "{{service}}"
      }]
    },
    {
      "type": "gauge",
      "title": "当前TPS",
      "targets": [{
        "expr": "sum(rate(order_created_total[1m]))"
      }]
    }
  ]
}

3. Linux实时吞吐量监控

# 网络吞吐量监控
nload -m eth0

# HTTP服务QPS监控
tail -f access.log | awk '{print $4}' | \
unix2dos | cut -c 14-21 | \
sort | uniq -c

# 输出示例：
# 120 [12/May/2023:15:01]
# 185 [12/May/2023:15:02]

六、明日即可应用的技能

1. 吞吐量快速评估公式

理论最大QPS = 1000 / 平均响应时间(ms) × 并发线程数
实际最大QPS = 理论最大QPS × 0.7（预留30%缓冲）

工作应用示例：

• 系统平均响应时间：50ms
• 服务器并发线程数：200
• 理论QPS = 1000/50 × 200 = 4000 QPS
• 建议生产配置：2800 QPS（4000×0.7）

2. 性能测试检查清单

吞吐量测试前检查

• 明确测试目标：QPS还是TPS？
• 确定基准值：当前生产环境吞吐量
• 设计合理场景：模拟真实用户行为
• 准备监控工具：JMeter+Prometheus
• 设置告警阈值：响应时间&错误率

测试中关注点

• 资源饱和度：CPU/内存/IO
• 错误类型：超时/5xx错误
• 吞吐量曲线：是否达到平台期

3. 优化优先级矩阵

工作口诀：
QPS量请求，TPS计事务
瓶颈先资源，再查阻塞处
优化看收益，监控不能忽

掌握吞吐量指标将使你在工作中：

1. 精准评估系统容量
2. 科学规划资源投入
3. 快速定位性能瓶颈
4. 量化优化效果价值
5. 提升系统稳定性与用户体验