性能分析之用户数(线程数)/响应时间/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的时候，压力工具采用的是：

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

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

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

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

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

那这样的曲线呢？

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

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

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

当然，这是不可能的。

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

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

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

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

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

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

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

巴特西