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