一、什么是并发

或许你在网上会得到"绝对并发"和"相对并发"这两个概念。绝对并发指的是同一时刻的并发数；相对并发指的是一个时间段内发生的事情。

但实际上，我们讲并发的时候不需要去区分上面这2个概念。为什么？

想象中的并发

假设上图中的这些小人是严格按照这个逻辑到达系统的，那显然，系统的绝对并发用户数是 4。如果描述 1 秒内的并发用户数，那就是 16。

实际中的并发

这些用户会分布在系统中不同的服务、网络等对象中。这时候"绝对并发"这个概念就难描述了，你说的是哪部分的绝对并发呢？

所以，在讲并发的时候，不用有“相对”和“绝对”的概念，这样可以简化沟通，也不会出错。

至于如何描述上面的并发用户数？可以直接用 TPS 来承载“并发”这个概念。

比如说，并发数是 16 TPS，就是指 1 秒内整个系统处理了 16 个事务。

依赖 TPS 来承载的时候，指的都是 Server 端的处理能力，并不是压力工具上的并发线程数。

二、计算并发用户数

并发用户数要基于在线用户数来计算，另外还有一个关键参数：并发度。

总共有 32 个用户进入了系统，但是绿色的用户并没有任何动作，那么显然，在线用户数是 32 个，并发用户数是 16 个，这时的并发度就是 50%。

三、压力工具中的线程数、响应时间和 TPS 的关系

首先，压力工具中的线程或用户数不是用来描述性能表现的。

"并发用户数"转化到"压力机的并发线程数"

可以先做一个基准测试。

比如，这里有个简单逻辑：

• JMeter（1 个线程） - Nginx - Tomcat - MySQL

此时，单个线程下 JMeter 的平均响应时间基本都在 5ms。所以它的 TPS 应该接近 1000ms / 5ms = 200TPS。

现在启动 10 个线程，平均响应时间在 25ms。现在的 TPS 应该接近 (1000ms / 25ms) * 10 = 400TPS。

那么，就有一个计算公式了：

所以，对于压力工具来说，只要不报错，我们就关心 TPS 和响应时间就可以了。因为 TPS 反应出来的是和服务器对应的处理能力，至于压力线程数是多少，并不关键。

四、总结

梳理在线用户数、并发用户数、TPS（这里假设了一个用户只对应一个事务）、响应时间之间的关系，需要注意：

• 通常所说的并发都是指服务端的并发，而不是指压力机上的并发线程数，因为服务端的并发才是服务器的处理能力。
• 性能中常说的并发，是用 TPS 这样的概念来承载具体数值的。
• 压力工具中的线程数、响应时间和 TPS 之间是有对应关系的。

在性能项目中，要简化概念，注重实用性。

本文参考：
高楼老师 性能测试实战30讲