最近在研究压力测试,有一个问题一直没有想明白,想请大家帮我答疑解惑。问题是关于压测中 TPS 和并发量。
我使用 Jmeter 对系统的某个接口进行 200 路并发压测,从聚合报告中可以看出:
关于 TPS 和并发量计算方法如下:
TPS = 系统每秒处理的事务数 = 某段时间系统处理的总请求数S / 某段时间 T = 4000 / 51 = 78.4 这个数据没有问题和jmeter展示的数据偏差不大
并发量 = 系统在某一时刻同时处理的事务数 = TPS * 平均响应时间 AVGRS = 78.4 * 1.961 = 153
我的疑惑就在:并发量和我在 jmeter 中设置的线程数 200 有什么关系,为什么并发数不是 200。
启 200 个线程不等于有 200 个并发吧
简单来说,
并发数:可以理解多少个并发用户,比如 200 并发数可以理解为有 200 个严格意义上的并发用户;
TPS: 每秒成功处理的事务数,或者每秒处理的接口请求;
为什么你的案例中,200 个并发,TPS 只有 78?
表面原因
当然也有其他原因会导致实际并发小于设置并发的情况:
比如压力机性能限制,无法支持 200 个并发线程,就会导致,你设置了 200 个并发用户,实际资源只启动了 100 个并发线程运行。
所以,TPS 与并发用户不一定总是线性关系。
二、指标
1、QPS(Queries Per Second)
概念:服务器每秒处理查询次数,是一台服务器每秒能够处理的查询次数。用户发起查询请求到服务器做出响应这算一次,一秒内用户完成了 50 次查询请求,那此时服务器 QPS 就是 50。
2、TPS(Transactions Per Second)
概念:服务器每秒处理的事务数,一个事物是用户发起查询请求到服务器做出响应这算一次。纳尼?这难道不是 QPS 的概念吗?划重点,这里就要说清楚一个概念了,在针对单接口,TPS 可以认为是等价于 QPS 的,如访问 ‘order.html’ 这个页面而言,是一个 TPS。而访问 ‘order.html’ 页面可能请求了 3 此服务器(如调用了 css、js、order 接口),这实际就算产生了三个 QPS
所以,总结下就是,在针对单接口的时候 TPS = QPS ,否则 QPS 就要看实际的请求次数了。
2、RT(Res(onse Time)
概念:响应实际,就是从客户端请求发起到服务器响应结果的时间。RT 这个参数是系统最重要的指标之一,它的大小直接反应了当前系统的响应状态。基本和咱们用户体验息息相关,现在好一点监控系统一般都有三个 RT,即平均、最大、最小。
一般系统 RT 100ms 以内是比较正常的,300ms 勉强可以接受,1s 的话再加上一些其他的外因,给用户的体验就是实实在在的不爽了。
3、并发数
概念:系统能同时处理的请求的数量,很多人经常会把并发数和 TPS 理解混淆。举例,请求一个 index.html 页面,客户端发起了三个请求(css、js、index 接口),那么此时 TPS =1 、QPS =3 、并发数 3。
SO,计算公式 :QPS=并发数/RT || 并发数=QPS*RT
4、吞吐量(Throughput)
概念:每秒承受的用户访问量,吞吐量(系统能承受多少压力)和当前请求对 CPU 消耗、内存、IO 使用等等紧密相关。单个请求消耗越高,系统吞吐量越低,反之越高。
一个系统的吞吐量和其 TPS 、QPS、并发数息息相关,每个系统针对这些值都有一个相对极限值,只要其中某一个达到最大,系统的吞吐量也就到达极限了。如此时压力继续增大,系统的吞吐量反而会下降,原因是系统超负荷工作,各种资源切换等等的消耗导致系统性能下降。
关系:
所以,理解上面几个关系后,就可以推算出:
QPS(TPS)= 并发数/平均响应时间
5、PV(Page View)
概念:即每个页面的浏览次数,用户每次刷新就算一次。
6、UV(Unique Visitor)
概念:独立访客数,每天访问的用户数,此数据需要根据用户唯一标识进行去重。
7、Load(系统负载)
概念:此数据指的是 Linux 系统的负载情况,也就是咱们平时所用 Top 命令时,最上面显示的数据信息 ( load average: 0.1, 0.2, 0.5)。此时会显示 1 分钟、5 分钟、15 分钟的系统平均 Load,很显然 load average 的值越低,你的系统负荷越小。
简单的说下这个值应该怎么看,如果你是单核 cpu,那此值为 1 的时候就是系统已经满负荷状态了,需要你马上去解决。但实际经验告诉我们,当系统负荷持续大于 0.7 的时候(也就是 70%),就需要你马上来解决问题了,防止进一步恶化。
为什么需要三个值 load average: 0.1, 0.2, 0.5,其实就是给你个参考。比如只有 1 分钟的是 1,其他俩都是 0.1,这表明只是临时突发的现象,问题不大。如果 15 分钟内,系统负荷都是 1 或大于 1,那表明问题持续存在啊。所以你应该主要观察 15 分钟的系统负荷。
1.我在 jmeter 中设置 200 个线程,那理论的并发数应该就是 200。
2.我计算出来的实际并发数是 153。
我可不可以这样理解,这个差值是由于:
服务器处理性能不足,导致我虽然让 200 个用户同时去登录,但是有部分用户的请求卡在了通道上,只有 153 个用户在登录,其余的处于等待状态。
等前面 153 个用户登录完了,剩下的 47 个用户才能去登录 (服务器才能处理这些请求)。
实际并发数 = 系统在某一时刻同时处理的事务数 = 某一时刻同时登录的用户数 = TPS * 平均响应时间 AVGRS = 78.4 * 1.961 = 153
你的推测有一定可能性,但是原因可能如下:
(1)被测服务最大连接数限制导致(这个可以查看一下当前连接数是否达到了最大连接数);
(2)被测服务资源有限,无更多资源分配给新建连接数导致;
(3)压力机资源限制,导致无更多资源分配给并发线程;
不是这么算的,这块的概念你没搞清楚。先查一下,什么叫实际并发数?
同一时刻同时登录的用户数 != TPS * 响应时间,这个公式完全不成立。
严格意义上的并发用户数:指与系统建立连接,并对系统发起请求,对系统造成压力的用户;
注意:并发用户数不能完全代表对系统的压力,比如 100 并发用户与系统建立了连接,每秒发一次请求,每 10 秒发一次请求,这两种行为对系统的压力是完全不一样的。
可以通过查询 被测服务器有多少来源于压力机的 IP 与服务器建立了连接,来计算真实并发。
亲,取 95% 或者 90% 的响应时间哦
你派遣了 200 个士兵(线程数)前去攻城
但是护城河上的桥(性能瓶颈)只允许 150 个士兵同时通行,剩下的士兵只能排队(所以 TPS 上不去了)
你 200 的并发设置集合点了吗,如果设置了集合点,又长时间跑的话,中间那个线程启动时间肯定是加到你的总时长里去了,况且计算 TPS 的时候为什么要除以总时长呢
所以结论是什么?
并发数=TPS * RT(平均响应时间)在未达到瓶颈时是成立的,达到瓶颈后就开始不成立了?
线程数当然不能等同于并发数了,难不成你想一条线程只输出一个 TPS?? 那假如我要 30000 并发,你要开 30000 线程? 那你 CPU 几 C 的?这会有多频繁的上下文切换?有多少资源耗费在其中?
实际并发数=发压端线程数每个线程输出的 TPS
TPS=(1000ms/平均响应事件)发压端线程数
你 TPS 不变的情况下,加线程数只能拉低响应时间,没有其他意义