性能分析之用户数(线程数)/响应时间/TPS的关系

最近在写一些东西的时候,把一些内容整理了一下。

在考虑压力工具中的用户数(有些工具中称为线程数,本文后续都用“用户数”来说明)、响应时间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的时候,压力工具采用的是:

  1. 先采集原始数据。即每个用户每个事务都记录下来。

  2. 再根据粒度计算。TPS散点值 = 事务数 / 粒度

这样的计算结果再通过曲线表现出来。就会受几个因素的影响:用户数、粒度、响应时间。

当粒度过大时,就会平均掉毛刺的影响;当粒度过小时,就会产生过多的事务点,让人抓狂。 

那到底什么样的TPS和响应时间是让人满意的呢?像这样吗?

响应时间随用户数上升而上升,TPS达到上限后变平;

这显然不是让人满意的曲线,因为我们希望的是响应时间不要增加那么快。

那这样的曲线呢?

响应时间有增加,但是增加的趋势并不快,TPS也一直有增加的趋势,这就显然系统还有容量的空间,就看性能指标该如何确定了。


我们多么希望这三者的关系像这个图呀。

响应时间从来没有增加过,TPS一直在增加,系统性能在测试范围内没有衰减。

当然,这是不可能的。

通常情况下,我们都要面对更复杂点的场景。如下图:

在这个非常简单的场景下,我们也看到了响应时间无理的跳动。还好幅度并不大。所以才保证了TPS在每个不同的用户梯度下相对的稳定。但是显然后面TPS已经达到上限了,响应时间开始增加得非常快。

对于这样的场景来说,已经算是非常清晰的用户数、TPS、RT的关系了。

而对于一些这三者关系根本找不到的性能场景,首先要做的就是要把场景判断清晰,让曲线变得稳定,再判断瓶颈,然后才是定位瓶颈及分析根本原因。

想让曲线变得稳定,就涉及到场景的执行策略了。

递增用户和场景的连续性是一定要保证的,只是梯度要根据实际的情况来判断。


今天先聊这么多,以后碰到有人问类似的问题再接着聊。


7DGroup微信公众号: 7DGroup

发表评论

电子邮件地址不会被公开。 必填项已用*标注