性能测试工具 求助个关于 TPS 的问题

得来全不费工夫 · April 08, 2018 · Last by 恒温 replied at April 12, 2018 · 2811 hits

因为要写一个slides,所以再次上网翻了下一些相关的资料,看到TPS的计算方法时,有点疑惑。

TPS的意思是每秒处理的事务。
但是我看到一篇文章是这样的:

(同样是20个入口,如果并发数变成100的话,TPS和响应时间会怎么样呢?
并发数到100的时候,就会出现堵车,堵车了平均每个车过去的时间就长了,把100个车按照20一份分成5份,第5份的等待时间就是最长的,从等待开始到这个车进去,实际花费了5秒,那100辆车都过去的响应时间就是(5+4+3+2+1)/5=3,平均的TPS就是(20/1+20/2+20/3+20/4+20/5)/5=9.13)


但我的理解是这样,这里100个车,总得通过时间不应该是最后一排车通过的时间,即5秒吗?那么TPS不应该是100/5=20吗?

另外关于并发,RT和TPS的关系,网上很容易看到是写着TPS=并发数/平均响应时间。

但是根据理发店模型来看的话,这个公式好像并不成立啊...比如1个来理发,用时一小时,那么TPS为1,并发为1,响应时间1.如果三个来理发,响应时间1,并发3(最优),TPS,是3. 如果是6个用户来理发,此时进入heavy load区域,此时throughput应该是基本稳定不再大幅增长,长时间运行时必然会导致部分用户离开(出错),但是此时如果按照TPS的算法的话,并发数为6,平均响应时间为1.5,那么TPS应该是4,好像并不符合理发店模型啊?

最佳回复

⚡ ⚡ ⚡ ⚡ ⚡ ⚡ ⚡ ⚡

1、理想情况:公式成立情况

TPS=并发数/平均响应时间
前提是服务器处理能力足够优秀,没有任何排队的情况下,网络耗时占响应时间极小的情况下,该公式成立。

2、实际情况:

TPS只跟服务器处理能力有关系,处理能力每秒多少,QPS或TPS就是多少(暂不考虑:因为排队导致资源紧张,导致服务处理能力下降)。

并发和tps、响应时间是关联关系,没有固定的公式、比例关系。更多的并发只能证明可能发出更多的请求,不能证明有更多的请求成功和服务器建联。


图中数字只是为了说明,并发、TPS并无直接联系,跟实际情况有关系。

共收到 41 条回复 时间 点赞

1 楼主摘选的文章没显示出来。
2 “TPS=并发数/平均响应时间” 这个公式不是用来计算TPS的,只是表明了他们三者之间的影响。
比如说,100个车在100s钟内通过(峰值)。那么TPS就是100/100=1。因为我们采样时间是100s。
如果增大并发量,发了1000个车,TPS是1不变(上面假设了1就是峰值),那么平均响应时间必然会增大。
所以说这个公式只是表面他们之间的关系,而非具体的算式。

pengshenshen 回复

就是那个括号里面的内容,就是摘抄的文章的,所以上面那个例子里,TPS的算法是对的吗?

TPS在服务器达到处理门限时,增加并发数TPS不会增加,而是响应时间会延长;服务器的处理能力没有提高的前提下TPS是相对固定的;

这里100个车,总得通过时间不应该是最后一排车通过的时间,即5秒吗?那么TPS不应该是100/5=20吗?

响应时间应该是获得服务器响应的时间。前20个车的响应时间是1s,后面的响应时间肯定会加长。

Bianca 回复

我知道响应时间会变大,不同批次响应时间已经不一样了,但是我只是想说,现在相当于100个车的话,最后全部通过是5秒,即5秒处理完了100个事务,那么TPS不应该就是100/5=20吗?

在路上 回复

所以我的理解是100个车通过20个口子的话,需要5秒,TPS极限是固定的都是20,只是因为后面几批的车辆通过时间(响应时间)变得越来越大,从整个样本上来说,无论是99%line,平均响应时间,都是变得越来越大的。对吧?所以我想说的是,看到的很多资料里面,tps的算法是有问题的。是不是?

是的,TPS是相对固定的,相信自己实践的数据,资料有的说的不完整;

你要理解TPS不是通过并发和响应时间来算的,虽然他们三者有一定的关系。
TPS也就是单位时间的事务处理能力,比如一百个闸机,每台车过去要1秒,那么它的TPS就是100,如果车辆有序通过,这个闸机的每秒通过车辆都是100,TPS也就是100。
但是如果车辆越来越多,造成闸机堵塞,或者其它意外情况,会造成TPS降低少于100的情况,所以压力持续增加,TPS会小于理想值。但是它的计算方法不是你这样算的。

雨夜狂奔 回复

我的算法和你是一样的,所以我才会有疑惑,因为看了很多帖子都是那种算法,感觉有点问题,因为无论是理发店模型还是高速口子的模型,TPS好像算出来应该是个固定值,而对于总样本的平均/99%等响应时间是会逐渐变大的,而跳出理想模型的话,实际中会出现tps衰减

在路上 回复

多谢

TPS的计算和平均响应时间没有关系。
我个人感觉那张经典的图比较清晰。

这个算式不太好。好多文章光贴这个算式出来,又不解释它含义,非常不负责。
如果非得强行解释这个算式的话,只能这样理解:
1) 当系统处理能力没有达到峰值时:并发量和TPS成正比关系,增大并发量,TPS会升高。因为系统资源没有耗尽,此时平均响应时间基本不变(实际可能略有上升)。
2)当系统资源耗尽时:此时TPS会维持稳定(实际可能略有下降),并发量和响应时间成正比关系,增大并发量的时候,平均响应时间一定会增大。

pengshenshen 回复

这个图知道的,所以才对网上看到的各种公式有疑问

TPS=并发数/平均响应时间是对的
TPS=总请求数/总请求耗时。
总请求数=并发量*总请求耗时/平均响应时间。

华全 回复

那如果按照高速入口这个模型的话,比如8辆车,4个口,那么第二排通过肯定是2秒,从TPS上来算,就是8/2=4,这样对不对?但是从并发数/平均响应时间来算的话,这里平均响应时间是(1X4+2X4)/8=1.5秒,按照你给出的算法的话,那么并发难道是8/1.5?

并发是TPS*平均响应时间,2*1.5 =3啊。
并发3是意味着一直保持有三辆车在过闸口。

要是你说一共只有8量车,那并发量其实是根据时间在递减的。
你想啊,过了1秒后,还剩4量车,这时候并发还是8么?

华全 回复

TPS是4,并发应该是6,但是这里不太对吧?从11楼的图上来看,不线性

TPS怎么算出来的是4?

华全 回复

4个口子啊,8辆车通过的话第二批需要2秒,总的时间就是2秒,而线程数有8,那么就是8/2=4啊

感觉你的视角有问题,要测路口,关注的只是这个条路每秒能过几辆车。 每辆用时多久。
并发数只是用来保证这条路是饱和的,每个口子都有车在过。四个口子的话只要保持4的并发即可。
就算加到一万辆车一起过,除了在过口子的车,其他车都是无效的压力。因为对于四个口子的路口来说他们当前也只承受了4个并发而已,后面的车他们感知不到的。

只有这条路有1W个口子可以并排开过1W辆车的时候,并发才算是1W

华全 回复

其实我的想法是,假设车子十秒还没通过口子,就不可接受(类似于系统的响应时间限制),这种情况下,就好知道最大可以承受多少并发吧?虽然对于入口来说他只能承受4个车通过,但是对于整个高速系统来说,他是可以接受线程在排队的

测最大可以承受多少并发很麻烦的。
不如用最大tps&当前的并发&响应时间估算

恒温 将本帖设为了精华贴 12 Apr 04:44

那到底哪个是正确的呢

恒温 回复

我问了不同的人,答案都是不同...但是Stack Overflow上回答也是TPS=并发数/响应时间,只是这里的响应时间指的是所有threads经历完的时间段,还是平均响应时间,并没有指出。

我觉得吧,括号里的2个计算没有太多意义,尤其是第2个;
TPS=并发数/响应时间,这个在没有到峰值时,是正确的,不管是总的响应时间还是平均响应时间,因为它是同一个值;
当我们知道峰值TPS的时候,在去用这个公式,显然没有太大意义,可能这时更多应该关注的是平均响应时间

Jacc 回复

摘抄自网上的资料,第二个算法我觉得是不对的

对于你说的100/5,我认为仅限于第1s的并发(或者说第一轮的并发,假如100/s的话,第1个100是5s,第2个100是9s,依次+4),因为此时已经超过峰值,这样算出来的值应该就是最大的TPS,然而现实中,做性能测试应该也不会这么(仅设1轮)去设置吧;像#11所说,还是应该理解每个值代表的意义,他们之间的影响关系

首先:
tps=每秒业务处理量=业务并发
你们讨论的线程并发是工具层产生的数据没有什么实际意义。
其次:
一般性能测试工具每个线程都是阻塞模型,一次res后才会进行下一次req,所以得到的数据必然是

  • 请求数量=测试并发线程/响应时间

最后:
如果调整策略 每秒固定请求个req,在测试线程里使用异步接收res话你就会发现你所谓的公式不对了。

心向东 回复

但是在模型中实际上是没有在考虑阻塞,不需要等前车res啊?愿闻其详

你连工具的实现都没弄明白吗?主流工具哪个不是阻塞模型?
我说的模型是内部的执行逻辑不是你的测试模型,至于工具层为什么这么设计 要细讲就要写一大篇了。
你只要明白性能测试 目标是找出tps峰值 并找出瓶颈点就行了,往这个目标做多半不会出差错,而新手性能人员的目标往往是压垮服务器,然后研究研究着就整歪了

心向东 回复

工具我知道目前都是阻塞的,没记错的国产有个麒麟还是什么名字的说是实现不一样。但是这里没有说工具,而是单指网上摘抄的例子里举得模型里,理想状态下他的tps是哪种算法?全部线程数/总时间,还是全部线程数(这个场景下的并发数)/平均响应时间

心向东 回复

另外不应该只是找出tps峰值,最终的结果没法抛开可接受的RT来谈tps

我在解释最后一遍 所谓公式:tps=并发线程/响应时间 中的tps是指 工具这边每秒发出的req的数量,如果工具的线程是阻塞型的那么这个req的tps==服务器的处理能力res 。
如果工具是非阻塞型的线程 每秒固定发出 xxx个req的话 如果服务器处理不过来 你觉得服务器的处理能力等于你的请求数量吗

RT又是啥,怎么老整这种奇怪的外文缩写

心向东 回复

所以在这个模型里面,入口就是服务端处理啊,已经限制了口子数和处理速度了,所以这个应该是固定的,而来车子多少只是client端的请求数

心向东 回复

response time啊

....你觉得你都测试到峰值了 你会拿不到response time吗??我说的是测试目标 不是测试结果 讨论问题能不能在一个层次😅

心向东 回复

哎...感觉相互没在一个频道上啊...😅

我的意思是把tps数据和线程中的并发扯到一起本来就是错误的行为会误导新人,而这个公式实际是计算美妙请求数的 ,在大多数时候恰好等于tps。所以讨论这个公式没有意义,只要把每个数据是什么怎么来的弄清楚自然没有问题了

⚡ ⚡ ⚡ ⚡ ⚡ ⚡ ⚡ ⚡

1、理想情况:公式成立情况

TPS=并发数/平均响应时间
前提是服务器处理能力足够优秀,没有任何排队的情况下,网络耗时占响应时间极小的情况下,该公式成立。

2、实际情况:

TPS只跟服务器处理能力有关系,处理能力每秒多少,QPS或TPS就是多少(暂不考虑:因为排队导致资源紧张,导致服务处理能力下降)。

并发和tps、响应时间是关联关系,没有固定的公式、比例关系。更多的并发只能证明可能发出更多的请求,不能证明有更多的请求成功和服务器建联。


图中数字只是为了说明,并发、TPS并无直接联系,跟实际情况有关系。

恒温 回复

这个帖子也加精?

zailushang 回复

讨论区加精。

恒温 取消了精华贴 12 Apr 16:38
需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up