一、什么是并发
或许你在网上会得到"绝对并发"和"相对并发"这两个概念。绝对并发指的是同一时刻的并发数;相对并发指的是一个时间段内发生的事情。
但实际上,我们讲并发的时候不需要去区分上面这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讲