一、什么是并发

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

但实际上,我们讲并发的时候不需要去区分上面这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讲