TPS (
transaction per second
)代表每秒执行的事务数量,可基于测试周期内完成的事务数量计算得出。
例如,用户每分钟执行
6
个事务,
TPS
为
6
/ 60s
= 0.10 TPS
。同时我们会知道事务的响应时间(或节拍),以此例,60秒完成6个事务也同时代表每个事务的响应时间或节拍为10秒。
利特尔法则
(Little’s law):
该法则由麻省理工大学斯隆商学院(MIT Sloan School of Management)的教授John Little﹐于1961年所提出与证明。它是一个有关提前期与在制品关系的简单数学公式,这一法则为精益生产的改善方向指明了道路。
利特尔法则的公式描述为:
Lead Time(
产出时间
)=
存货数量
×
生产节拍 或
TH(
生产效率
)= WIP(
存货数量
)/ CT(
周期时间
)
P.S: 稍后我们会列出负载模型中利特尔法则的应用公式。
我们通过2个示例来看一下此法则是如何在生产环境中发生作用的。
例
1
:假定我们所开发的并发服务器,并发的访问速率是:
1000
客户
/
分钟,每个客户在该服务器上将花费平均
0.5
分钟,根据
little's law
规则,在任何时刻,服务器将承担
1000×0.5
=
500
个客户量的业务处理。假定过了一段时间,由于客户群的增大,并发的访问速率提升为
2000
客户
/
分钟。在这样的情况下,我们该如何改进我们系统的性能?
根据
little's law
规则,有两种方案:
第一:提高服务器并发处理的业务量,即提高到
2000×0.5
=
1000
。
或者
第二:减少服务器平均处理客户请求的时间,即减少到:
2000×0.25
=
500
。
例
2
:假设你排队参观某个风景点,该风景点固定的容纳人数是:
60
人。每个人在该风景点停留的平均时间是:
3
分钟。假设在你的前面还排有
20
个人,问:你估计你大概等多少时间才能进入该风景点。
答案:
1
小时(
3×20=60
),和该景点固定的容纳人数无关。
为了通过
利特尔法则研究负载模型,我们就先要了解两个因子:
响应时间(
Response time
)和节拍(
Pacing
)。实际上节拍会超越响应时间对TPS的影响。
示例
1
:节拍
0秒,
思考时间
0秒
用户执行
5
个事务并且每个事务的响应时间是
10
秒,需要花费
50
秒完成
5
个事务,即
5/50=0.1 TPS (
这里
TPS
是由响应时间控制
)。
示例
2
:速率
15
秒,思考时间
0秒
用户执行
5
个事务且每个事务的响应时间是
10
秒,但实际由于节拍大于响应时间,所以它优于响应时间控制了事务发生的频率。完成5个事务需要
5*15 = 75秒,产生
5/75=0.06667 TPS。
在第二个示例中,平均响应时间小于节拍15秒,需要75秒完成5个迭代,产生了0.06667 TPS。
上面两个例子中我们假设思考时间为0秒。如果思考时间为2秒,总时间仍是75秒完成5个迭代,产生0.06667 TPS。
节拍为0秒,则
用户数 = TPS * ( 响应时间 + 思考时间 )
节拍不为0秒且大于响应时间与思考时间的和,则
用户数 = TPS * (速率)
事实上TPS是事务在w.r.t时间的速率,所以也被称为吞吐量(throughput)。
所以
利特尔法则在负载模型中解释为:
系统内平均用户数 = 平均响应时间 * 吞吐量
N = ( R + Z ) * X
N, 用户数
R, 平均响应时间(也可能是速率)
Z, 思考时间
X, 吞吐量(如TPS)
如:
N (用户数)=1500, R (平均响应时间)=10, Z (思考时间)=0,则X (吞吐量)=1500/10=150 TPS