Azure 指标中的百分位数 - Web 应用程序缓慢是什么？

Question

我需要知道 Azure 指标中的百分位数 - Web 应用程序缓慢。我正在尝试在诊断下分析 Azure 中的 Web 应用程序缓慢功能。有 3 个图例 - 第 50 个百分位、第 90 个百分位、第 95 个百分位。

Answer 1

Martin Kleppmann写了一本很棒的书，名为“设计数据密集型应用程序”。

\n

在这本书中，马丁描述了为什么我们应该更喜欢百分位数而不是中位数。

\n

这里我引用一点摘录相关讨论：

\n

即使您只是一遍又一遍地发出相同的请求，您\xe2\x80\x99每次尝试都会得到略有不同的响应时间。实际上，在处理各种请求的系统中，响应时间可能会有很大差异。因此，我们需要将响应时间视为一个分布，而不是一个单一的数字可测量的值的

\n

在图 1-4 中，每个灰色条代表对服务的请求，其高度显示该请求花费的时间。大多数请求都相当快，但偶尔也会出现异常值需要更长的时间。也许缓慢的请求本质上更昂贵，例如，因为它们处理更多的数据。但即使在您\xe2\x80\x99d 认为所有请求应该花费相同时间的情况下，您也会遇到变化：上下文切换到后台进程、网络数据包丢失和 TCP 重传可能会引入随机的额外延迟、垃圾收集暂停、强制从磁盘读取的页面错误、服务器机架中的机械振动或许多其他原因。

\n

\n图1-4。说明平均值和百分位数：对服务的 100 个请求样本的响应时间。

\n

查看报告的服务的平均响应时间是很常见的。（严格来说，术语 \xe2\x80\x9caverage\xe2\x80\x9d 并不指代任何特定公式，但实际上它通常被理解为算术平均值：给定n 个值，将所有值相加值，然后除以n。）但是，如果您想知道您的 \xe2\x80\x9c典型\xe2\x80\x9d 响应时间，平均值并不是一个很好的指标，因为它不告诉\xe2\x80\x99您有多少用户实际经历过这种延迟。

\n

通常最好使用百分位数。如果您获取响应时间列表并将其从最快到最慢排序，那么中位数就是中间点：例如，如果您的中位数响应时间是 200 毫秒，这意味着一半的请求在不到 200 毫秒的时间内返回，一半的请求在 200 毫秒内返回。您的请求需要比这更长的时间。

\n

如果您想知道用户通常需要等待多长时间，这使得中位数成为一个很好的指标：一半的用户请求在不到中位数响应时间的时间内得到满足，而另一半则需要比中位数更长的时间。中位数也称为第 50 个百分位数，有时缩写为p50。注意，中位数指的是单个请求；如果用户发出多个请求（在一个会话过程中，或者因为单个页面中包含多个资源），则至少其中一个请求比中值慢的概率远大于 50%。

\n

为了弄清楚异常值有多严重，您可以查看较高的百分位数：第95、99和99.9个百分位数很常见（缩写为p95、p99和p999）。它们是响应时间阈值，在该阈值下，95%、99% 或 99.9% 的请求比该特定阈值快。例如，如果第 95 个百分位响应时间为 1.5 秒，则意味着 100 个请求中有 95 个花费的时间少于 1.5 秒，而 100 个请求中有 5 个花费的时间为 1.5 秒或更长。如图 1-4 所示。

\n

响应时间的高百分位数（也称为尾部延迟）非常重要，因为它们直接影响用户\xe2\x80\x99 的服务体验。例如，亚马逊用 99.9% 的百分位来描述内部服务的响应时间要求，尽管它只影响千分之一的请求。这是因为请求最慢的客户通常是那些帐户上拥有最多数据的客户，因为他们进行了多次购买\xe2\x80\x94，也就是说，他们\xe2\x80\x99是最有价值的客户。确保网站速度快，让这些客户满意非常重要：亚马逊还观察到，响应时间增加 100 毫秒，销售额就会减少 1%，而其他人则报告说，响应时间增加 1 秒，销售额就会减少 1%。客户满意度指标提高了 16%。

\n

另一方面，优化第 99.99 个百分位（万分之一的请求中最慢的一个）被认为过于昂贵，并且无法为 Amazon\xe2\x80\x99s 的目的带来足够的好处。减少非常高的百分位数的响应时间很困难，因为它们很容易受到您无法控制的随机事件的影响，并且带来的好处正在减少。

\n

例如，百分位数通常用于服务级别目标(SLO) 和服务级别协议(SLA)、定义服务的预期性能和可用性的合同。SLA 可能规定，如果服务的中值响应时间小于 200 毫秒且第 99 个百分位数低于 1 秒（如果响应时间更长，则服务可能会关闭），则该服务被视为已启动，并且该服务可能需要至少 99.9% 的时间处于运行状态。这些指标设定了服务客户的期望，并允许客户在未满足 SLA 的情况下要求退款。

\n

排队延迟通常占高百分位响应时间的很大一部分。由于服务器只能并行处理少量的事情（例如，受 CPU 核心数量的限制），因此只需要少量的慢速请求即可阻止后续请求的处理\xe2\x80\x94an这种效应有时称为队头阻塞。即使服务器上处理这些后续请求的速度很快，客户端也会因为等待先前请求完成的时间而看到整体响应时间很慢。由于这种影响，测量客户端的响应时间非常重要。

\n

当为了测试系统的可扩展性而人为生成负载时，负载生成客户端需要独立于响应时间持续发送请求。如果客户端在发送下一个请求之前等待上一个请求完成，则该行为会人为地使测试中的队列比实际情况短，从而使测量结果出现偏差。

\n

实践中的百分位数

\n

高百分位数在后端服务中变得尤其重要，这些服务作为服务单个最终用户请求的一部分被多次调用。即使您并行进行调用，最终用户请求仍然需要等待最慢的并行调用完成。只需一次缓慢的调用就会使整个最终用户请求变慢，如图 1-5 所示。即使只有一小部分后端调用速度缓慢，如果最终用户请求需要多个后端调用，则获得缓慢调用的机会也会增加，因此较高比例的最终用户请求最终会变得缓慢（这种效应称为尾潜伏期放大）。

\n

如果您想将响应时间百分位数添加到服务的监控仪表板中，则需要持续有效地计算它们。例如，您可能希望保留过去 10 分钟内请求响应时间的滚动窗口。每分钟，您都会计算该窗口中值的中位数和各个百分位数，并将这些指标绘制在图表上。

\n

最简单的实现是保留时间窗口内所有请求的响应时间列表，并每分钟对该列表进行排序。如果这对您来说效率太低，有一些算法可以以最小的 CPU 和内存成本计算出百分位数的近似值，例如前向衰减、t-digest 或 HdrHistogram。请注意，平均百分位数（例如，降低时间分辨率或合并来自多台机器的数据）在数学上没有意义\xe2\x80\x94聚合响应时间数据的正确方法是添加直方图。

\n

\n图1-5。当需要多个后端调用来服务一个请求时，只需一个缓慢的后端请求即可减慢整个最终用户请求的速度。

\n