一、什么是并发
或许你在网上会得到"绝对并发"和"相对并发"这两个概念。绝对并发指的是同一时刻的并发数；相对并发指的是一个时间段内发生的事情。
但实际上，我们讲并发的时候不需要去区分上面这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 之间是有对应关系的。
在性能项目中，要简化概念，注重实用性。
