TPS、并发数与线程数

定义：

TPS：单位时间（每秒）处理的事务数。

并发数：同一时刻系统同时处理的请求数（相对并发，绝对并发）。

线程数：一般情况下，指是的虚拟用户数。

1 两个场景

场景一：登录接口能够承受秒级 1000 并发。

那么，这里的并发是TPS？还是并发数？还是线程数？如果是你，你会如何解读呢？说说个人的理解：一般情况下，在做性能测试时，都不会去强调并发的概念。因为现实的场景中，除了秒杀、整点开抢等几类特殊的场景外，都不会进行狭义上的并发测试。所以，这里的1000并发，应该指的是TPS为1000。

场景二：已知TPS是1000，如何估算出系统支持的最大在线用户数？

这个是无法通过理论知识来估算出来的。因为这两者本身就没有什么直接的关系。用户在线，并不一定产生请求，又或者这些请求也不是我们要测试的场景。

2 澄清三者关系

并发数较好说，分为强并发和弱并发。所谓的强并发指的是单位时间内，同时请求的数量。类似的场景就是秒杀活动或者整点活动这类的场景。而我们通常说的并发，指的都是一段时间内（可以是秒级，也可以是分钟级的），系统能够处理的数据总量。这更符合我们的实际场景。

基于上面的概念，TPS = Vu（总请求数）/Time（响应时间+思考时间）

我们在模拟大批量的请求时，不太可能自己手动去点。所以需要借助工具来模拟。这就涉及到了线程数。通常情况下，一个线程数代表一个用户，在我们计划的执行时间或者执行次数下，向服务器发起请求。所以线程数只是我们模拟请求的概念，和实际的性能问题没有直接的关系，服务端只关心在一段时间内，处理了多少请求，并不关心这些请求是从哪里来的。如果你的负载机性能足够好，那么单位时间内，10000个请求，你可以用100个线程执行100次，也可以用1000个线程执行10次。这完全是负载机的问题，虽然达到服务端的时间会有微小的差异，但基本上可以忽略。

3 TPS与响应时间

其实，我们在描述系统的性能能力时，只说TPS是不够的。还需要考虑到响应时间和系统资源使用率，系统资源使用率在没太大瓶颈的前提下，可以不谈，但是不谈响应时间就不应该了。例如，有两个系统，TPS都是1000，但A系统的响应时间是0.5S，B系统的响应时间是2S，你觉得哪个系统的性能好？明显可以看出，A系统的TPS还有很大的提升空间。

4 TPS中的T

一般情况下，我们在讲TPS时，都是讲单接口的TPS，也可以是QPS（每秒查询事务数）。但是在实际的工作场景中，某一个T（Transactions）都会有由若干个接口共同完成。很多性能测试工具，都提供了自定义Transactions的功能。因为这个Transactions才是描述客户行为的真实场景。所以在性能测试报告中，我们需要告诉用户你是如何定义Transactions的。不同的定义方法，TPS会有较大的差异。不能为了追求数值上的好看，而忽略了真实场景。