共计 1095 个字符，预计需要花费 3 分钟才能阅读完成。
最近在写一些货色的时候，把一些内容整顿了一下。
在思考压力工具中的用户数（有些工具中称为线程数，本文后续都用“用户数”来阐明）、响应工夫、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 的关系了。
而对于一些这三者关系基本找不到的性能场景，首先要做的就是要把场景判断清晰，让曲线变得稳固，再判断瓶颈，而后才是定位瓶颈及剖析根本原因。
想让曲线变得稳固，就波及到场景的执行策略了。
递增用户和场景的连续性是肯定要保障的，只是梯度要依据理论的状况来判断。
明天先聊这么多，当前碰到有人问相似的问题再接着聊。