性能测试三TPS 和并发数是什么关系？

Posted 2023-04-05 把苹果咬哭的测试笔记

一、什么是并发

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

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

性能测试指标：TPS，吞吐量，并发数，响应时间

性能测试指标：TPS，吞吐量，并发数，响应时间

常用的网站性能测试指标有：TPS、吞吐量、并发数、响应时间、性能计数器等。

并发数
并发数是指系统同时能处理的请求数量，这个也是反应了系统的负载能力。

响应时间
响应时间是一个系统最重要的指标之一，它的数值大小直接反应了系统的快慢。响应时间是指执行一个请求从开始到最后收到响应数据所花费的总体时间。

吞吐量
吞吐量是指单位时间内系统能处理的请求数量，体现系统处理请求的能力，这是目前最常用的性能测试指标。

QPS（每秒查询数）、TPS（每秒事务数）是吞吐量的常用量化指标，另外还有HPS（每秒HTTP请求数）。

跟吞吐量有关的几个重要是：并发数、响应时间。

QPS（TPS），并发数、响应时间它们三者之间的关系是：

QPS（TPS）= 并发数/平均响应时间

性能计数器
性能计数器是描述服务器或操作系统性能的一些数据指标，如使用内存数、进程时间，在性能测试中发挥着“监控和分析”的作用，尤其是在分析统统可扩展性、进行新能瓶颈定位时有着非常关键的作用。

Linux中可以使用 top 或者 uptime 命令看到当前系统的负载及资源利用率情况。

资源利用率：指系统各种资源的使用情况，如cpu占用率为68%，内存占用率为55%，一般使用“资源实际使用/总的资源可用量”形成资源利用率。

$ top
top - 15:47:21 up 4 days, 19:57,  7 users,  load average: 0.00, 0.00, 0.00
Tasks: 109 total,   1 running, 108 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.5%us,  0.5%sy,  0.0%ni, 98.8%id,  0.0%wa,  0.0%hi,  0.2%si,  0.0%st
Mem:   1922368k total,  1845156k used,    77212k free,   163552k buffers
Swap:  4128760k total,    22284k used,  4106476k free,   637292k cached

所以，一个网站优化的目的即是，最大限度的利用好服务器硬件资源提升资源利用率，减少用户请求的响应时间，提高系统吞吐量，提高系统并发数。

 

吞吐量与并发数的关系

吞吐量：一段时间内应用系统处理用户的请求数（以下介绍指单位时间内，也可以理解为吞吐率），这个定义考察点一般是系统本身因素；当然也可以用单位时间内流经被测系统的数据流量，一般单位为b/s,即每秒钟流经的字节数，这个定义的考察点既有系统本身因素也有网络，外设等因素，也可以理解为除客户端以外的测试环境及被测系统。

并发用户数：指同一时间点对业务功能同时操作的用户数，可以分为两种：一种是严格意义上的并发，即所有的用户在同一时刻做同一件事或操作，这时业务功能一般指同一类型的业务；另外一种并发是广义范围的并发，这种并发与前一种并发的区别是，尽管多个用户对系统发出了请求或者进行了操作，但是这些请求或都操作可以是相同的，也可以是不同的，这时业务功能可能不是同一类型的业务。

再看看两则有没有关联，上网查了下资料有些资料说有关系，有些说没有直接关系，下面说说我的看法： 并发数 >= 吞吐量

一般来说，在系统的设计范围之内，吞吐量随系统的并发用户数的增加呈现增加趋势，也就是说你客户端来多少请求数系统吃（处理）多少请求数；当超出这个范围时有两种情况，一种是系统只能处理这么多，超过这个数系统不接收了，最后随着并发用户数的增多吞吐量是一个水平的直线；

还有一种情况是不管来多少系统都接收最后导致系统吞吐量下降甚至系统崩溃。并发用户数是客户端单位时间内对服务器端施加的压力，具体能不能接受并处理要看被测系统的吞吐量，而吞吐量是被测系统单位时间内处理的请求数或者说单位时间内处理的字节数；一个着重于客户端的操作即测试手段，一个着重于应用系统的处理能力即查看对象；（上面的讨论没有考虑两者的单位，如一个用户同时有多个请求情况）

最后顺便把两者的计算公式注明下：

平均并发用户数的计算：C=nL / T

其中C是平均的并发用户数，n是平均每天访问用户数，L是一天内用户从登录到退出的平均时间（操作平均时间），T是考察时间长度（一天内多长时间有用户使用系统）

并发用户数峰值计算： C^约等于C + 3*根号C 其中C^是并发用户峰值，C是平均并发用户数，该公式遵循泊松分布理论。（该公式针对一般被测系统，特殊不做讨论）

吞吐量计算：当没有遇到性能瓶颈的时候，吞吐量与虚拟用户数之间存在一定的联系，可以采用以下公式计算：F=VU * R / T其中F为吞吐量，VU表示虚拟用户个数，R表示每个虚拟用户发出的请求数，T表示性能测试所用的时间，其实通过这个公式就能看出吞吐量与并发用户数之间的关系了（这里的VU就是我们用工具模拟的并发用户数）。

 

并发数、QPS、平均响应时间三者之间关系

 

 

原文地址http://www.sohu.com/a/256477206_100224606

原文地址https://blog.csdn.net/youanyyou/article/details/78990209