这篇文章主要介绍“什么是Little’s Law”，在日常操作中，相信很多人在什么是Little’s Law问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”什么是Little’s Law”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！在引出今天的主角Little’s Law之前，有必要先统一一下我们描述“性能”的“基本语言”，毕竟语言不通是没法交流的不是。不同的服务设备对性能的定义也不同，例如CPU主要看主频，磁盘主要看IOPS。本文主要针对后端的软件服务性能（比如api服务，数据库服务等）展开讨论。限定好范围后就应该给出一个性能的定义了：性能就是服务的处理请求的能力。衡量性能的指标常见的有三个：并发用户数、吞吐量、响应时间。指真正对服务发送请求的用户数量，需要注意和在线用户数的区别； 比如，某一时刻，在线用户数为1000，其中只有100个用户的操作触发了与远端服务的交互， 那么这时对远端服务来说，并发用户数是100，而不是1000。单位时间内处理的请求数。对应的英文是response time,也有的地方用 latency表示，即延迟。 需要统计一个时间段内的响应时间，求出特征值来表示响应时间。 常见的特征值包括平均值、最大值、最小值、分位值。稳定的系统中同时被服务的用户数量等于用户到达系统的速度乘以每个用户在系统中驻留的时间，适用于所有需要排队的场景。 对应公式表示为：比如说，你正在排队进入一个体检中心，你可以通过估计人们进入的速率来知道自己还要等待多长时间。前一部分说的三个指标的关系可以用Little’s Law来表示，因为对用户请求不断发送到服务端进行处理的情况来说，就是一种排队的场景，把Little’s Law具体到这种场景那么对应的公式为：下面主要从接口服务和mysql服务两个实例来观察Little’s Law的存在。基于springboot暴露一个接口 接口本身会根据参数值休眠一段时间，这样客户端的压测工具就可以控制接口的响应时间了。通过jmeter设置不同的并发数对上面的接口进行压测 初始阶段响应时间基本稳定，吞吐量随着并发数的增加而增加； 随着并发数增加，系统到达“拐点”，吞吐量开始出现下降的趋势，同时响应时间也开始增大；继续增加并发数，系统负载超负荷，从而进入过饱和区，此时响应时间急剧增大，吞吐量急剧下降。在“拐点”之前和刚进入拐点这段区域，此时可以认为系统为“稳定”的，此时并发数、吞吐量、平均响应时间是符合Little’s Law公式的。准备一个腾讯云mysql服务（5.6版本，配置为2核4G）和一台云服务器（腾讯云内网测试）用sysbench(0.5版本)对mysql服务进行测试初始阶段响应时间基本稳定，吞吐量随着并发数的增加而增加； 随着并发数增加，系统到达“拐点”，吞吐量开始出现下降的趋势，同时响应时间也开始增大；继续增加并发数，系统负载超负荷，从而进入过饱和区，此时响应时间急剧增大，吞吐量急剧下降。在“拐点”之前和刚进入拐点这段区域，此时可以认为系统为“稳定”的，此时并发数、吞吐量、平均响应时间是符合Little’s Law公式的。基于前述的两个实测的例子，对于并发数、吞吐量、响应时间三者的关系，我们可以用上图表示。刚开始为“线性增长区”，此时响应时间基本稳定，吞吐量随着并发用户数的增加而增加；当系统的资源利用率饱和时，系统到达“拐点”，随着并发用户数增加，吞吐量开始出现下降的趋势，同时响应时间也开始增大；继续增加并发用户数，系统负载超负荷，从而进入过饱和区，此时响应时间急剧增大，吞吐量急剧下降。在“拐点”之前和刚进入拐点这段区域，此时可以认为系统为“稳定”的，此时并发数、吞吐量、平均响应时间是符合Little’s Law公式的。比如你这样设置jmeter的线程数为80，测出的结果并不是说你的服务在80个用户使用情况下的性能表现，实际场景中可能1000个真实用户产生的压力也没有这里的80个线程（或者叫虚拟用户数）产生的压力大。我倾向于把并发数理解为一种压力的度量，80的并发对服务的压力肯定是大于60的并发对服务的压力的。假如一个程序只有1个线程，这个线程每秒可以处理10次事件，那么我们说这个程序处理单次事件的延迟为100ms，吞吐为10次/秒。假如一个程序有4个线程，每个线程每秒可以处理5次事件，那么我们说这个程序处理单次事件的延迟为200ms，吞吐为20次/秒。假如一个程序有1个线程，每个线程每秒可以处理20次事件，那么我们说这个程序处理单次事件的延迟为50ms，吞吐为20次/秒。由Little’s Law我们知道，并发数=吞吐量*响应时间，所以延迟和吞吐的关系是受并发数影响的，抛开并发数去找另外两者的关系是没有规律的。性能如果只看吞吐量，不看响应时间是没有意义的。从前面的分析我们知道，随着并发数的逐渐增加，吞吐量有一个先上升再下降的过程，也就是存在同一个吞吐量的值，在不同并发下，会对应不同的响应时间。比如某接口吞吐量为10000TPS,响应时间达到5秒，那这个10000TPS也没什么意义了。比如在接口测试中，当并发数达到4000时，错误率达到了40%，那么此时的1270.8TPS就没什么意义了。 我理解的服务的性能就是又多又快又好的处理请求，“多”就是吞吐量大，“快”就是响应时间短，“好”就是错误率尽量低。在Little’s Law中我们一直用的响应时间是“平均响应时间”，而实际工作中我们通常用响应时间的“分位值”来作为响应时间的统计值来衡量性能的，平均值只是作为一个辅助参考。原因你应该懂得，比如“平均工资”通常没多大参考价值，有可能很多人是被平均的。Eric Man Wong 于2004年发表的《Method for Estimating the Number of Concurrent Users》论文中介绍了一种对系统并发用户数估算的公式：这个公式和Little’s Law是等价的，具体论述过程参考Eric’s并发用户数估算与Little定律的等价性到此，关于“什么是Little’s Law”的学 香港云主机习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注开发云网站，小编会继续努力为大家带来更多实用的文章！
这篇文章主要讲解了“HTTP中长连接和短连接的区别”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“HTTP中长连接和短连接的区别”吧！在HTTP/1.0中默认使用短连接。也就是说，客户端和服务器每进行一次HTTP…
免责声明：本站发布的图片视频文字，以转载和分享为主，文章观点不代表本站立场，本站不承担相关法律责任；如果涉及侵权请联系邮箱：360163164@qq.com举报，并提供相关证据，经查实将立刻删除涉嫌侵权内容。
微信扫一扫 
