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