最近在写一些东西的时候,把一些内容整理了一下。
在考虑压力工具中的用户数(有些工具中称为线程数,本文后续都用“用户数”来说明)、响应时间、TPS三者之间的关系时,想到之前也有人问起过这样的问题,就是他们三者之间的共生的关系到底是什么样呢。
这个公式我想谁都能知道了:
TPS = ( 1 / RT ) * user (其中,RT单位是秒,user是用户数)
先来画一下最简单的图(假设前提:每个user的事务定义都是一致的。):
当有五个用户时,响应时间都稳定保持在0.2s,那这个场景的TPS显然是:
TPS = (1/0.2)*5 = 25
这是最简单的计算了。
(也许你会说:“咳,不对,因为线画歪了!”
你过来,我保证揍不死你。)
这个看似简单的公式,在实际的场景中却是会出现千奇百怪的结果。因为大部分的场景都不会如此规整,例如:
这种情况下怎么计算TPS呢:
TPS = 2 + 4 + 6 + 4 + 1 = 17
显然响应时间也是变化较大的,可能每个用户的每个事务的响应时间都是不一样的。
在真实的场景中,这样的情况是必然会出现的,所以在计算TPS的时候,压力工具采用的是:
-
先采集原始数据。即每个用户每个事务都记录下来。
-
再根据粒度计算。TPS散点值 = 事务数 / 粒度
这样的计算结果再通过曲线表现出来。就会受几个因素的影响:用户数、粒度、响应时间。
当粒度过大时,就会平均掉毛刺的影响;当粒度过小时,就会产生过多的事务点,让人抓狂。
那到底什么样的TPS和响应时间是让人满意的呢?像这样吗?
响应时间随用户数上升而上升,TPS达到上限后变平;
这显然不是让人满意的曲线,因为我们希望的是响应时间不要增加那么快。
那这样的曲线呢?
响应时间有增加,但是增加的趋势并不快,TPS也一直有增加的趋势,这就显然系统还有容量的空间,就看性能指标该如何确定了。
我们多么希望这三者的关系像这个图呀。
响应时间从来没有增加过,TPS一直在增加,系统性能在测试范围内没有衰减。
当然,这是不可能的。
通常情况下,我们都要面对更复杂点的场景。如下图:
在这个非常简单的场景下,我们也看到了响应时间无理的跳动。还好幅度并不大。所以才保证了TPS在每个不同的用户梯度下相对的稳定。但是显然后面TPS已经达到上限了,响应时间开始增加得非常快。
对于这样的场景来说,已经算是非常清晰的用户数、TPS、RT的关系了。
而对于一些这三者关系根本找不到的性能场景,首先要做的就是要把场景判断清晰,让曲线变得稳定,再判断瓶颈,然后才是定位瓶颈及分析根本原因。
想让曲线变得稳定,就涉及到场景的执行策略了。
递增用户和场景的连续性是一定要保证的,只是梯度要根据实际的情况来判断。
今天先聊这么多,以后碰到有人问类似的问题再接着聊。