1.前言
开发的同学或多或少都会跟“性能”这个玩意打交道，本文将要介绍的 Little’s Law 跟衡量性能的常见指标关系密切，所以在引出今天的主角 Little’s Law 之前，有必要先统一一下我们描述“性能”的“基本语言”，毕竟语言不通是没法交流的不是。另外，以下叙述都是我的个人理解，不当之处请指正。
2.“性能”的“基本语言”
不同的服务设备对性能的定义也不同，例如 CPU 主要看主频，磁盘主要看 IOPS。本文主要针对后端的软件服务性能（比如 api 服务、数据库服务等）展开讨论。限定好范围后就应该给出一个性能的定义了：性能就是服务的处理请求的能力。
衡量性能的指标常见的有三个：并发用户数、吞吐量、响应时间。
2.1 并发用户数
指真正对服务发送请求的用户数量，需要注意和在线用户数的区别；
比如，某一时刻，在线用户数为 1000，其中只有 100 个用户的操作触发了与远端服务的交互，那么这时对远端服务来说，并发用户数是 100，而不是 1000。
2.2 吞吐量
单位时间内处理的请求数。
2.3 响应时间
对应的英文是 response time，也有的地方用 latency 表示，即延迟。需要统计一个时间段内的响应时间，求出特征值来表示响应时间。
常见的特征值包括平均值、最大值、最小值、分位值。
3.主角 Little’s Law 登场
3.1 Little’s Law 的定义
稳定的系统中同时被服务的用户数量等于用户到达系统的速度乘以每个用户在系统中驻留的时间，适用于所有需要排队的场景。
对应公式表示为：
比如说，你正在排队进入一个体检中心，你可以通过估计人们进入的速率来知道自己还要等待多长时间。
3.2 Little’s Law 与性能指标的关系
前一部分说的三个指标的关系可以用 Little’s Law 来表示，因为对用户请求不断发送到服务端进行处理的情况来说，就是一种排队的场景，把 Little’s Law 具体到这种场景那么对应的公式为：
3.3 通过实例感受 Little’s Law 的存在
下面主要从接口服务和 mysql 服务两个实例来观察 Little’s Law 的存在。
3.3.1 接口服务的实例
3.3.1.1 准备过程介绍
基于 springboot 暴露一个接口
接口本身会根据参数值休眠一段时间，这样客户端的压测工具就可以控制接口的响应时间了。
通过 jmeter 设置不同的并发数对上面的接口进行压测
3.3.1.2 结果展示与分析
初始阶段响应时间基本稳定，吞吐量随着并发数的增加而增加；
随着并发数增加，系统到达“拐点”，吞吐量开始出现下降的趋势，同时响应时间也开始增大；继续增加并发数，系统负载超负荷，从而进入过饱和区，此时响应时间急剧增大，吞吐量急剧下降。在“拐点”之前和刚进入拐点这段区域，此时可以认为系统为“稳定”的，此时并发数、吞吐量、平均响应时间是符合 Little’s Law 公式的。
3.3.2 mysql 服务的实例
3.3.2.1 准备过程介绍
准备一个腾讯云 mysql 服务（5.6 版本，配置为 2 核 4G）和一台云服务器（腾讯云内网测试）
用 sysbench(0.5 版本)对 mysql 服务进行测试
3.3.2.2 结果展示与分析
初始阶段响应时间基本稳定，吞吐量随着并发数的增加而增加；
随着并发数增加，系统到达“拐点”，吞吐量开始出现下降的趋势，同时响应时间也开始增大；继续增加并发数，系统负载超负荷，从而进入过饱和区，此时响应时间急剧增大，吞吐量急剧下降。在“拐点”之前和刚进入拐点这段区域，此时可以认为系统为“稳定”的，此时并发数、吞吐量、平均响应时间是符合 Little’s Law 公式的。
4.总结
4.1 Little’s Law 公式系统“稳定”时成立
基于前述的两个实测的例子，对于并发数、吞吐量、响应时间三者的关系，我们可以用上图表示。
刚开始为“线性增长区”，此时响应时间基本稳定，吞吐量随着并发用户数的增加而增加；
当系统的资源利用率饱和时，系统到达“拐点”，随着并发用户数增加，吞吐量开始出现下降的趋势，同时响应时间也开始增大；
继续增加并发用户数，系统负载超负荷，从而进入过饱和区，此时响应时间急剧增大，吞吐量急剧下降。
在“拐点”之前和刚进入拐点这段区域，此时可以认为系统为“稳定”的，此时并发数、吞吐量、平均响应时间是符合 Little’s Law 公式的。
4.2 并发数并不是实际用户数
比如你这样设置 jmeter 的线程数为 80，测出的结果并不是说你的服务在 80 个用户使用情况下的性能表现，实际场景中可能 1000 个真实用户产生的压力也没有这里的 80 个线程（或者叫虚拟用户数）产生的压力大。我倾向于把并发数理解为一种压力的度量，80 的并发对服务的压力肯定是大于 60 的并发对服务的压力的。
4.3 低延迟（响应时间）不一定高吞吐，高延迟（响应时间）也不一定低吞吐
假如一个程序只有 1 个线程，这个线程每秒可以处理 10 次事件，那么我们说这个程序处理单次事件的延迟为 100ms，吞吐为 10 次/秒。
假如一个程序有 4 个线程，每个线程每秒可以处理 5 次事件，那么我们说这个程序处理单次事件的延迟为 200ms，吞吐为 20 次/秒。
假如一个程序有 1 个线程，每个线程每秒可以处理 20 次事件，那么我们说这个程序处理单次事件的延迟为 50ms，吞吐为 20 次/秒。
由 Little’s Law 我们知道，并发数=吞吐量*响应时间，所以延迟和吞吐的关系是受并发数影响的，抛开并发数去找另外两者的关系是没有规律的。
4.4 响应时间要和吞吐量挂钩
性能如果只看吞吐量，不看响应时间是没有意义的。从前面的分析我们知道，随着并发数的逐渐增加，吞吐量有一个先上升再下降的过程，也就是存在同一个吞吐量的值，在不同并发下，会对应不同的响应时间。比如某接口吞吐量为 10000TPS,响应时间达到 5 秒，那这个 10000TPS 也没什么意义了。
4.5 响应时间、吞吐量和成功率要挂钩
比如在接口测试中，当并发数达到 4000 时，错误率达到了 40%，那么此时的 1270.8TPS 就没什么意义了。
4.6 又多又快又好
我理解的服务的性能就是又多又快又好的处理请求，“多”就是吞吐量大，“快”就是响应时间短，“好”就是错误率尽量低。
4.7 last but not least
在 Little’s Law 中我们一直用的响应时间是“平均响应时间”，而实际工作中我们通常用响应时间的“分位值”来作为响应时间的统计值来衡量性能的，平均值只是作为一个辅助参考。原因你应该懂得，比如“平均工资”通常没多大参考价值，有可能很多人是被平均的。
5.扩展
Eric Man Wong 于 2004 年发表的《Method for Estimating the Number of Concurrent Users》论文中介绍了一种对系统并发用户数估算的公式：
这个公式和 Little’s Law 是等价的，具体论述过程参考Eric’s并发用户数估算与Little定律的等价性
6.参考
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论