最近遇到了两个关于性能测试的场景，发现有三个很多人理不清楚的概念：TPS、并发数及线程数。这三者到底有什么关系呢？其实概念是相对简单的，但是在使用的时候，往往会有很多混淆的情况出现。
先说定义：
TPS：单位时间（每秒）处理的事务数。
并发数：同一时刻系统同时处理的请求数（相对并发，绝对并发）。
线程数：一般情况下，指是的虚拟用户数。
你看，是不是很清晰？
1
两个场景
场景一：登录接口能够承受秒级 1000 并发。
那么，这里的并发是TPS？还是并发数？还是线程数？如果是你，你会如何解读呢？说说个人的理解：一般情况下，在做性能测试时，都不会去强调并发的概念。因为现实的场景中，除了秒杀、整点开抢等几类特殊的场景外，都不会进行狭义上的并发测试。所以，这里的1000并发，应该指的是TPS为1000。
场景二：已知TPS是1000，如何估算出系统支持的最大在线用户数？
这个是无法通过理论知识来估算出来的。因为这两者本身就没有什么直接的关系。用户在线，并不一定产生请求，又或者这些请求也不是我们要测试的场景。所以请求那些面试官或者产品经理能否尊重下性能测试？不要再问这些没有逻辑的问题？如果真想了解如何评估系统容量，请系统的学习下相关知识，而不是拿一个TPS强人所难。
2
澄清三者关系
并发数较好说，分为强并发和弱并发。所谓的强并发指的是单位时间内，同时请求的数量。类似的场景就是秒杀活动或者整点活动这类的场景。而我们通常说的并发，指的都是一段时间内（可以是秒级，也可以是分钟级的），系统能够处理的数据总量。这更符合我们的实际场景。
基于上面的概念，TPS = Vu（总请求数）/Time（响应时间+思考时间），（这里暂不考虑网络传输的时间，思考时间也可以忽略吧，你们的脚本会考虑这些么？复杂问题简单化）。而Vu（总请求数）是怎么来的？
我们在模拟大批量的请求时，不太可能自己手动去点。所以需要借助工具来模拟。这就涉及到了线程数。通常情况下，一个线程数代表一个用户，在我们计划的执行时间或者执行次数下，向服务器发起请求。所以线程数只是我们模拟请求的概念，和实际的性能问题没有直接的关系，服务端只关心在一段时间内，处理了多少请求，并不关心这些请求是从哪里来的。如果你的负载机性能足够好，那么单位时间内，10000个请求，你可以用100个线程执行100次，也可以用1000个线程执行10次。这完全是负载机的问题，虽然达到服务端的时间会有微小的差异，但基本上可以忽略。
3
TPS与响应时间
其实，我们在描述系统的性能能力时，只说TPS是不够的。还需要考虑到响应时间和系统资源使用率，系统资源使用率在没太大瓶颈的前提下，可以不谈，但是不谈响应时间就不应该了。例如，有两个系统，TPS都是1000，但A系统的响应时间是0.5S，B系统的响应时间是2S，你觉得哪个系统的性能好？明显可以看出，A系统的TPS还有很大的提升空间嘛。就像你能考100分，是你努力的结果，而学霸考100分是因为卷面只有100分。对于A系统，应该继续往上压，找出更好的TPS，而对于B系统，差不多要进行调优了。
4
TPS中的T
一般情况下，我们在讲TPS时，都是讲单接口的TPS，也可以是QPS（每秒查询事务数）。但是在实际的工作场景中，某一个T（Transactions）都会有由若干个接口共同完成。很多性能测试工具，都提供了自定义Transactions的功能。因为这个Transactions才是描述客户行为的真实场景。所以在性能测试报告中，我们需要告诉用户你是如何定义Transactions的。不同的定义方法，TPS会有较大的差异。不能为了追求数值上的好看，而忽略了真实场景。
5
小结
理清基础的概念，有助于指导我们在真实场景下的落地实践。不要过于纠结并发数，这个指标更多的是体现负载机的性能，通过TPS 结合响应时间，才能更好地反馈系统的性能问题。同时，性能测试是个系统的专项工程，它有自己的方法论和评估体系，需要从业者更深入地了解和学习，而不是为了几个指标去做性能测试。别人可能因为不专业，所以不清楚，但我们是从业者，应该有能力去帮助产品或者客户澄清这些疑问，而不是听之任之。
6
预告
本周三（4月13号）晚上9点，我将会和老张、CC一起聊聊质量内建的话题，欢迎大家预约收看
