性能测试中TPS、并发数与线程数的关系
在性能测试中，我们经常会遇到这样的需求：测试系统在多少并发数、多少 TPS（每秒事务数）下的表现。那并发是否等于线程？如何估算线程数？
这篇文章将围绕这些问题展开，帮助你理清 TPS、并发数与线程数之间的关系。
什么是TPS
TPS（Transactions Per Second），即每秒事务数，TPS是用于衡量系统每秒可以处理的事务数量，常用于评估应用程序的性能和可扩展性。
如何定义“事务”？
在性能测试中，事务（Transaction）通常指一个具有完整业务意义的操作过程。
例如，在一个电商系统中，提交订单可以被视为一个事务，虽然这个事务涉及多个接口调用或操作（如验证库存、生成订单、扣减余额、发送通知等），只要这个操作在业务上是原子的、完整的，有意义的就可以视为一个事务。
如何计算TPS
计算每秒事务数的公式：TPS = 总事务数 / 测试持续时间（秒），假设在一次性能测试中：
- 总共成功处理了 3000 个事务
- 测试持续时间为 60 秒
3000除以60=50 TPS，系统在该测试中平均每秒处理 50 个事务，所以此时的TPS是50
什么是并发数和线程数
在解释并发数和线程数的关系之前，我们先了解“并发”的两种不同描述方式：
- 绝对并发是在一个接口或事务提交前先集合，然后尽量在同一个时间点内进行操作的并发，比如常见的秒杀场景
- 相对并发是在一段时间内，同时有多少用户或线程在对系统进行访问，有些用户可能比较活跃有些用户的操作较少，也就是说有些用户活跃度相对高。
性能测试中经常会有要求提到压多少多少并发， 首先我们要明确一个概念，这边的并发是某一时刻系统中同时发起请求并处于处理中的数量，它反映的是服务端的处理压力，而非是客户端的。
如何估算需要多少线程？
那1个并发数是否就等于1个压测工具中的线程呢 , 如何知道需要多少线程呢，回答是不一定
- 如果每个线程 TPS 高、响应快，少量线程就能达到目标并发
- 如果响应相对慢、线程的等待或空闲时间较长，就可能需要更多的线程才能撑起并发数
我们可以进一步用经验公式计算具体的线程数：线程数≈目标并发数×(1+ 思考时间 / 总共响应时间)
示例
- 目标并发用户数：100
- 响应时间：0.2 秒
- 思考时间：1.8 秒
首先计算活跃度
活跃度 = 0.2 / 1.8 + 2 = 10% = 0.1
根据经验公式计算
线程数 = 100/0.1 = 100×(1+0.2 / 1.8) = 100 × (1+9)=1000
所以在接口平均响应时间0.2的情况下要实现目标100并发大约需要1000个线程，而不是100个线程
如何通过目标TPS估算多少线程
在性能测试中如果我们的目标是压到多少TPS，那如何从TPS反推出需要多少线程呢。
核心思路就是计算每个线程大约每秒可以制造多请求，也就是每个线程的TPS大约是多少，然后就可以反推出总共需要多少线程。
示例：目标 TPS = 1000
场景一：单接口压测
接口的平均响应时间：0.1秒 ，线程设置每次请求间的思考时间：0.4秒
1 / 0.1 + 0.4 = 1 / 0.5 = 2TPS
线程数 = 1000TPS / 2 = 500
每个线程可以提供2的TPS，所以总共大约需要500个线程完成1000TPS
场景二：多接口混合压测
在真实项目中，压测场景往往涉及多个接口，并且它们的响应时间和调用频率不同。这时不建议直接取平均值，而是应使用加权平均响应时间。假设有以下三个接口：
| 接口名 | 响应时间（秒） | 思考时间 | 占比（调用频率） |
|---|---|---|---|
| A | 0.1 | 0.1 | 60% |
| B | 0.3 | 0.3 | 30% |
| C | 1.0 | 0.4 | 10% |
计算接口响应时间的加权平均值
R（avg） = 0.1 * 60% + 0.3 % 30% + 1.0 * 10% = 0.06 + 0.09 + 0.10 = 0 .25 秒
计算加权平均思考时间
T(AVG) = 0.1 * 60% + 0.3 * 30% + 0.4 * 10% = 0.19秒
这时打出 1000 TPS 大约需要441个线程
每个线程TPS = 1 / 0.25 + 0.19 = 2.27
线程数 = 1000 / 2.27 = 441