认识达内从这里开始

想想大家在使用电脑程序或者是APP软件的时候会发现，经过一段时间之后这些程序的反应速度都会下降，而今天我们就一起来了解一下，造成程序运行效率降低的原因都有哪些。

按理说，每一次手机上生成请求的时间、将请求传输给Web服务的时间、查询用户的时间、返回结果并显示下一个屏幕的时间应该是一样的。造成响应时间长短不一的是排队时间，也就是等待正在处理其他请求的资源。从手机到认证服务器之间的网络传输需要经过很多跳，每一跳前面都有等待被发送的数据包。如果队列是空的或者队列很短，那么响应速度就很快，如果队列很长，响应就很慢。当请求达到服务器时，也需要排队等待CPU处理。如果需要查询数据库，还需要排到另一个队列里。

排队等待是导致响应时间增加的主要原因。

监控工具会提供一个叫作吞吐量(Throughput)的指标，用来度量处理频度。在某些情况下，我们也会得到一个叫作到达率(ArrivalRate)的指标，用于度量到达服务器的请求的速率。在理想情况下，比如一个具有稳定工作负载状态的Web服务，一个请求对应一个响应，那么吞吐量和到达率是一样的。不过，重试和错误会导致到达率增加，但吞吐量不会增加。对于快速变化的工作负载或者需要长时间处理的请求(比如批次作业)，会出现到达率和吞吐量之间的不均衡，并产生更为复杂的请求模式。

吞吐量是指已经成功处理完的请求数量，它跟达到率是不一样的。

我们可以通过一些跟踪系统(比如Zipkin或AWSX-Ray)来跟踪单个请求流，不过我们这里讨论的是大量请求以及它们之间的交互关系。我们通过固定的时间间隔来度量均值，时间间隔可以是秒、分钟、小时或天。计算均值需要足够多的数据，一般来说每个均值至少需要20个数据点。

如果请求不是很频繁，请选择一个至少包含20个请求的时间间隔，这样才有可能得到比较有用的信息。

如果选择的时间间隔太大，会导致工作负载的变化被隐藏掉。例如，对于视频会议系统来说，大部分会话会在一个小时的头一分钟左右启动，并且很容易在这些时间段达到峰值，让系统发生过载，如果时间间隔是小时，这些信息就会丢失掉。所以，对于这种情况，时间间隔设为秒更为恰当。

对于变化快的工作负载，可以使用秒级的均值。

监控工具各种各样，但一般很少会直接告诉我们等待队列有多长或有多少并发度可用来处理队列。大多数网络每次只传输一个数据包，但CPU的每个核心或vCPU可以并行处理队列里的任务。数据库通常有一个固定的大连接数，用来限制并发度。

对于处理请求的每一个步骤，可以记录或估计用于处理请求的并发度。

如果系统运行稳定，有稳定的平均吞吐量和响应时间，那就很容易估算等待队列的长度，只需要将吞吐量和驻留时间相乘即可。这就是所谓的利特尔法则法则(Little’sLaw)。这个法则很简单，监控工具经常用它来估算队列长度，但它只对具有稳定均值的系统有效。

根据利特尔法则，平均队列长度=平均吞吐量*平均驻留时间。

为了更好地理解这个法则的原理，我们需要知道请求是如何到达服务器以及请求之间的间隔是怎样的。如果我们通过循环进行简单的性能测试，请求之间的间隔是固定的，那么利特尔法则就无效，因为这样出现的队列很短，而且这样的测试不真实。我们通常会进行这样的测试，以为很完美，但是在将服务部署到生产环境之后，眼睁睁地看着它越跑越慢，吞吐量越来越低。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!更多内容请在707945861群中学习了解。