在性能测试中，TPS（每秒事务数） 是衡量系统处理能力的关键指标。但很多测试同学在计算 TPS 时容易陷入误区，导致测试结果失真。本文将结合 JMeter 官方文档与真实案例，详解 TPS 的正确计算方法及常见问题，助你避开性能测试的“深坑”！

---

一、什么是 TPS？为什么它如此重要？

TPS（Transactions Per Second）表示系统每秒能处理的事务数量。例如，一个电商平台的支付接口 TPS 为 100，意味着每秒可处理 100 笔支付请求。
重要性：

• 高 TPS 代表系统在高并发下仍能稳定运行；
• 低 TPS 可能暴露性能瓶颈（如数据库慢查询、代码死锁等）。

---

二、TPS 的常见计算方法及误区

1. 错误方法：并发数 ÷ 平均响应时间

公式：TPS = 并发线程数 / 平均响应时间
问题：

• 假设系统资源无限：实际中，线程数增加会导致资源争用（如数据库连接池耗尽），响应时间非线性增长，TPS 无法按公式线性提升。
• 忽略长尾效应：平均响应时间可能被少数慢请求拉高，导致 TPS 虚高。
  示例：
• 100 并发线程，平均响应时间 2 秒 → 公式计算 TPS=50。
• 实际场景：若 10% 请求耗时 10 秒，总测试时间被拖长至 10 秒，真实 TPS=总请求数/总时间=100/10=10，仅为公式值的 1/5。

2. 正确方法：总事务数 ÷ 总测试时间

公式：TPS = 总完成事务数 / 总测试时间
JMeter 官方支持：

• 通过监听器（如 Summary Report）直接获取 Throughput（即 TPS），公式为：
  Throughput = (样本数) / (最后一个请求结束时间 - 第一个请求开始时间)。
  示例：
• 总事务数 200，测试时长 4 秒 → TPS=200/4=50。
• 即使存在长尾效应，该公式仍能准确反映实际吞吐量。

---

三、JMeter 中 TPS 的获取方式

1. 使用内置监听器

• Summary Report：直接显示 Throughput（TPS）和平均响应时间。

• 

• Transactions per Second（需插件）：实时展示 TPS 波动曲线，适合分析稳定性。

2. 手动计算

• 测试时间计算：
  • 开始时间：第一个请求的启动时间（MIN(请求开始时间)）。
  • 结束时间：最后一个请求的完成时间（MAX(请求开始时间 + 响应时间)）。
• 公式应用：

  TPS = 成功请求数 / (结束时间 - 开始时间)  
  

---

四、TPS 计算的常见问题与解决方案

1. 长尾效应导致误差

• 问题：少数慢请求拉高平均响应时间，TPS 虚高。
• 解决方案：
  • 使用 95% Line 响应时间（95% 请求的耗时低于此值）替代平均值。
  • 示例：若 95% Line=1.5 秒，仅 5% 请求超过此值，更能反映真实性能。

2. 未扣除思考时间（Think Time）

• 问题：用户操作间隔被计入响应时间，导致 TPS 计算偏低。
• 解决方案：
  • 在 JMeter 中添加 定时器（如 Constant Timer）模拟用户等待。
  • 调整公式：TPS = 并发数 / (响应时间 + Think Time)。

3. 资源争用导致虚假高响应时间

• 问题：线程因等待资源（如数据库连接）阻塞，JMeter 记录的响应时间虚高。
• 解决方案：
  • 监控服务器资源（CPU、内存、连接池），优化瓶颈。
  • 示例：数据库连接池满时，实际处理时间 0.1 秒，但 JMeter 记录 10 秒，需通过资源监控定位问题。

---

五、JMeter 官方建议与最佳实践

1. 避免依赖平均值：优先使用 Throughput 监听器 和 95% Line 指标。
2. 梯度加压测试：使用插件（如 Stepping Thread Group）逐步增加并发，观察 TPS 拐点。
3. 结合监控工具：如服务器 CPU、内存、JVM 监控，关联分析 TPS 下降原因。

---

六、总结

正确计算 TPS 需避开“并发数 ÷ 平均响应时间”的误区，以总事务数 ÷ 总时间为标准，并结合 JMeter 监听器与系统监控综合分析。性能测试不是数学公式的简单套用，而是资源、代码、架构的全链路优化过程！