C# Azure度量中的百分位是什么-Web应用程序速度慢？

我需要知道Azure metric-Web应用程序中的百分比是多少。我正在尝试分析Azure中诊断中的Web应用程序慢速功能。有3个图例-第50百分位、第90百分位、第95百分位

写了一本很棒的书，名为

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

在这里，我引用一些相关的讨论：

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

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

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

报告服务的平均响应时间是很常见的。（严格来说，术语“平均值”并不指任何特定的公式，但在实践中，它通常被理解为算术平均值：给定n个值，将所有值相加，然后除以n。）然而，如果你想知道你的“典型”响应时间，平均值不是一个很好的指标，因为它没有告诉你有多少用户实际经历了延迟

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

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

为了弄清楚你的异常值有多糟糕，你可以看看更高的百分位数：第95、99和99.9百分位数是常见的（缩写为p95、p99和p999）。它们是95%、99%或99.9%的请求比特定阈值快的响应时间阈值。例如，如果第95个百分位响应时间为1.5秒，则表示100个请求中有95个请求的响应时间不到1.5秒，100个请求中有5个请求的响应时间不超过1.5秒。如图1-4所示

高百分比的响应时间（也称为尾部延迟）非常重要，因为它们直接影响用户对服务的体验。例如，Amazon以99.9%的百分比来描述内部服务的响应时间要求，尽管它只影响1000个请求中的1个。这是因为请求速度最慢的客户往往是那些拥有最多账户数据的客户，因为他们购买了很多东西，也就是说，他们是最有价值的客户。通过确保网站对客户来说是快速的来保持客户满意是很重要的：亚马逊还观察到，响应时间增加100毫秒会减少1%的销售额，而其他人则报告说，1秒钟的延迟会减少16%的客户满意度指标

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

例如，百分比通常用于服务级别目标（SLO）和服务级别协议（SLA），这些合同定义了服务的预期性能和可用性。SLA可能会声明，如果服务的平均响应时间小于200 ms，且第99个百分位数小于1s（如果响应时间更长，则它也可能处于关闭状态），则该服务被视为处于启动状态，并且该服务可能需要至少99.9%的时间处于启动状态。这些指标设定了服务客户的期望值，并允许客户在未满足SLA时要求退款

排队延迟通常占高百分位响应时间的很大一部分。由于服务器只能并行处理少量的事情（例如，受其CPU内核数量的限制），因此只需要少量的慢速请求就可以延迟后续请求的处理，这种效果有时被称为行首阻塞（head-of-line blocking）。即使这些后续请求在服务器上处理得很快，但由于等待前一个请求完成的时间过长，客户端的总体响应时间也会很慢。由于这种影响，在客户端测量响应时间非常重要

当人工生成负载以测试系统的可伸缩性时，负载生成客户端需要独立于响应时间发送请求。如果