我需要知道Azure指标中的百分比- Web应用程序缓慢。我正在尝试在诊断下分析Azure中的Web应用程序缓慢功能。有3个图例-第50百分位数、第90百分位数、第95百分位数。
zu0ti5jz1#
Martin Kleppmann写了一本很棒的书，叫Designing Data-Intensive Applications。在这本书中，马丁描述了为什么我们应该更喜欢百分位数而不是中位数。这里我引用一点excerpt的相关讨论：即使您只是一遍又一遍地发出相同的请求，每次尝试都会得到稍微不同的响应时间。实际上，在处理各种请求的系统中，响应时间可能会有很大的变化。因此，我们不需要将响应时间视为一个单一的数字，而是可以测量的值的分布。在图1-4中，每个灰色条表示对服务的请求，其高度显示该请求花费的时间。大多数请求都相当快，但偶尔会有一些异常值需要更长的时间。可能慢请求本质上更昂贵，例如，因为它们处理更多数据。但是，即使在您认为所有请求都应该花费相同时间的情况下，您也会得到变化：随机的附加等待时间可由到后台进程的上下文切换、网络分组和TCP重传的丢失、垃圾收集暂停、强制从盘读取的页面错误、服务器机架中的机械振动或许多其它原因引入。x1c 0d1x图1-4。* 说明平均值和百分位数：对服务的100个请求的响应时间。*通常会看到报告的服务的 * 平均 * 响应时间。（严格地说，术语“平均值”并不指任何特定的公式，但在实践中，它通常被理解为 * 算术平均值 *：给定n个值，将所有值相加，然后除以 n。）但是，如果您想知道“典型”响应时间，则平均值不是一个非常好的度量，因为它不能告诉您实际上有多少用户经历了该延迟。通常最好使用 percentiles。如果你把你的响应时间列表从最快到最慢排序，那么 * 中位数 * 就是中间点：例如，如果您的平均响应时间是200毫秒，这意味着您的请求中有一半在不到200毫秒的时间内返回，而您的请求中有一半的时间超过了200毫秒。这使得中位数成为一个很好的指标，如果你想知道用户通常需要等待多长时间：一半的用户请求在不到中位数的响应时间内得到处理，另一半则需要超过中位数的时间。中位数也称为 * 第50百分位数 ，有时缩写为 p50。注意，中位数指的是单个请求;如果用户发出几个请求（在会话过程中，或者因为几个资源被包括在单个页面中），则它们中的至少一个比中值慢的概率远大于50%。为了弄清楚你的离群值有多糟糕，你可以看看更高的百分位数： 95 th 、 99 th * 和 99.9th 百分位数是常见的（缩写为 p95、p99 和 p999）。它们是95%、99%或99.9%的请求比特定阈值快的响应时间阈值。例如，如果第95百分位数的响应时间是1.5秒，这意味着100个请求中有95个请求花费的时间少于1.5秒，100个请求中有5个请求花费的时间为1.5秒或更长。如图1-4所示。响应时间的高百分位数，也称为“尾部延迟”，非常重要，因为它们直接影响用户对服务的体验。例如，Amazon以99.9%的百分比来描述内部服务的响应时间要求，即使它只影响1，000个请求中的1个。这是因为请求最慢的客户通常是那些在其帐户上拥有最多数据的客户，因为他们进行了许多购买，也就是说，他们是最有价值的客户。重要的是要通过确保网站对他们来说是快速的来让这些客户满意：亚马逊还观察到，响应时间增加100毫秒会使销售额减少1%，而其他人报告说，1秒的延迟会使客户满意度指标降低16%。另一方面，优化第99.99百分位数（最慢的1/10，000请求）被认为过于昂贵，并且无法为亚马逊的目的带来足够的好处。在非常高的百分位数下减少响应时间是很困难的，因为它们很容易受到您无法控制的随机事件的影响，并且好处正在减少。例如，百分位数通常用于 * 服务水平目标 *（SLO）和 * 服务水平协议 *（SLA），这些合同定义了服务的预期性能和可用性。SLA可以声明，如果服务具有小于200 ms的中值响应时间和小于Is的第99百分位数，则服务被认为是开启的（如果响应时间更长，则它也可能是关闭的），并且服务可以被要求在至少99.9%的时间内是开启的。这些指标为服务的客户设定了期望，并允许客户在不满足SLA的情况下要求退款。
排队延迟通常占响应时间的很大一部分。由于服务器只能并行处理少量的事情（例如，受其CPU内核数量的限制），因此只需要少量的慢速请求就可以阻止后续请求的处理-这种效果有时称为 * 行首阻塞 *。即使这些后续请求在服务器上处理得很快，客户端也会看到由于等待先前请求完成的时间而导致的缓慢的总体响应时间。由于这种影响，测量客户端的响应时间非常重要。当为了测试系统的可伸缩性而人为地生成负载时，负载生成客户端需要保持独立于响应时间发送请求。如果客户端在发送下一个请求之前等待上一个请求完成，则该行为会人为地使测试中的队列比实际中的队列更短，这会使测量结果发生偏差。
在后端服务中，高百分比变得特别重要，因为作为服务单个最终用户请求的一部分，后端服务被多次调用。即使并行进行调用，最终用户请求仍然需要等待最慢的并行调用完成。只需要一个慢调用就可以使整个最终用户请求变慢，如图1-5所示。即使只有一小部分后端调用很慢，如果最终用户请求需要多个后端调用，那么获得慢调用的机会就会增加，因此最终用户请求的比例会更高（这种效应称为“尾部延迟放大”）。如果您希望将响应时间百分比添加到服务的监视 Jmeter 板中，则需要持续有效地计算它们。例如，您可能希望保留最近10分钟内请求响应时间的滚动窗口。每一分钟，您都要计算该窗口中值的中位数和各个百分位数，并将这些指标绘制在图表上。简单的实现是为时间窗口内的所有请求保留一个响应时间列表，并每分钟对该列表进行排序。如果这对你来说效率太低，有一些算法可以以最小的CPU和内存成本计算出一个很好的百分位数近似值，比如前向衰减、t-digest或HdrHistogram。注意，平均百分位数，例如，降低时间分辨率或合并来自几台机器的数据，在数学上是没有意义的-聚合响应时间数据的正确方法是添加直方图。
图1-5。* 当需要多个后端调用来处理一个请求时，只需要一个缓慢的后端请求就可以减慢整个最终用户请求的速度。*
1条答案
按热度按时间zu0ti5jz1#
Martin Kleppmann写了一本很棒的书，叫Designing Data-Intensive Applications。
在这本书中，马丁描述了为什么我们应该更喜欢百分位数而不是中位数。
这里我引用一点excerpt的相关讨论：
即使您只是一遍又一遍地发出相同的请求，每次尝试都会得到稍微不同的响应时间。实际上，在处理各种请求的系统中，响应时间可能会有很大的变化。因此，我们不需要将响应时间视为一个单一的数字，而是可以测量的值的分布。
在图1-4中，每个灰色条表示对服务的请求，其高度显示该请求花费的时间。大多数请求都相当快，但偶尔会有一些异常值需要更长的时间。可能慢请求本质上更昂贵，例如，因为它们处理更多数据。但是，即使在您认为所有请求都应该花费相同时间的情况下，您也会得到变化：随机的附加等待时间可由到后台进程的上下文切换、网络分组和TCP重传的丢失、垃圾收集暂停、强制从盘读取的页面错误、服务器机架中的机械振动或许多其它原因引入。
x1c 0d1x图1-4。* 说明平均值和百分位数：对服务的100个请求的响应时间。*
通常会看到报告的服务的 * 平均 * 响应时间。（严格地说，术语“平均值”并不指任何特定的公式，但在实践中，它通常被理解为 * 算术平均值 *：给定n个值，将所有值相加，然后除以 n。）但是，如果您想知道“典型”响应时间，则平均值不是一个非常好的度量，因为它不能告诉您实际上有多少用户经历了该延迟。
通常最好使用 percentiles。如果你把你的响应时间列表从最快到最慢排序，那么 * 中位数 * 就是中间点：例如，如果您的平均响应时间是200毫秒，这意味着您的请求中有一半在不到200毫秒的时间内返回，而您的请求中有一半的时间超过了200毫秒。
这使得中位数成为一个很好的指标，如果你想知道用户通常需要等待多长时间：一半的用户请求在不到中位数的响应时间内得到处理，另一半则需要超过中位数的时间。中位数也称为 * 第50百分位数 ，有时缩写为 p50。注意，中位数指的是单个请求;如果用户发出几个请求（在会话过程中，或者因为几个资源被包括在单个页面中），则它们中的至少一个比中值慢的概率远大于50%。
为了弄清楚你的离群值有多糟糕，你可以看看更高的百分位数： 95 th 、 99 th * 和 99.9th 百分位数是常见的（缩写为 p95、p99 和 p999）。它们是95%、99%或99.9%的请求比特定阈值快的响应时间阈值。例如，如果第95百分位数的响应时间是1.5秒，这意味着100个请求中有95个请求花费的时间少于1.5秒，100个请求中有5个请求花费的时间为1.5秒或更长。如图1-4所示。
响应时间的高百分位数，也称为“尾部延迟”，非常重要，因为它们直接影响用户对服务的体验。例如，Amazon以99.9%的百分比来描述内部服务的响应时间要求，即使它只影响1，000个请求中的1个。这是因为请求最慢的客户通常是那些在其帐户上拥有最多数据的客户，因为他们进行了许多购买，也就是说，他们是最有价值的客户。重要的是要通过确保网站对他们来说是快速的来让这些客户满意：亚马逊还观察到，响应时间增加100毫秒会使销售额减少1%，而其他人报告说，1秒的延迟会使客户满意度指标降低16%。
另一方面，优化第99.99百分位数（最慢的1/10，000请求）被认为过于昂贵，并且无法为亚马逊的目的带来足够的好处。在非常高的百分位数下减少响应时间是很困难的，因为它们很容易受到您无法控制的随机事件的影响，并且好处正在减少。
例如，百分位数通常用于 * 服务水平目标 *（SLO）和 * 服务水平协议 *（SLA），这些合同定义了服务的预期性能和可用性。SLA可以声明，如果服务具有小于200 ms的中值响应时间和小于Is的第99百分位数，则服务被认为是开启的（如果响应时间更长，则它也可能是关闭的），并且服务可以被要求在至少99.9%的时间内是开启的。这些指标为服务的客户设定了期望，并允许客户在不满足SLA的情况下要求退款。
排队延迟通常占响应时间的很大一部分。由于服务器只能并行处理少量的事情（例如，受其CPU内核数量的限制），因此只需要少量的慢速请求就可以阻止后续请求的处理-这种效果有时称为 * 行首阻塞 *。即使这些后续请求在服务器上处理得很快，客户端也会看到由于等待先前请求完成的时间而导致的缓慢的总体响应时间。由于这种影响，测量客户端的响应时间非常重要。
当为了测试系统的可伸缩性而人为地生成负载时，负载生成客户端需要保持独立于响应时间发送请求。如果客户端在发送下一个请求之前等待上一个请求完成，则该行为会人为地使测试中的队列比实际中的队列更短，这会使测量结果发生偏差。
实际百分位数
在后端服务中，高百分比变得特别重要，因为作为服务单个最终用户请求的一部分，后端服务被多次调用。即使并行进行调用，最终用户请求仍然需要等待最慢的并行调用完成。只需要一个慢调用就可以使整个最终用户请求变慢，如图1-5所示。即使只有一小部分后端调用很慢，如果最终用户请求需要多个后端调用，那么获得慢调用的机会就会增加，因此最终用户请求的比例会更高（这种效应称为“尾部延迟放大”）。
如果您希望将响应时间百分比添加到服务的监视 Jmeter 板中，则需要持续有效地计算它们。例如，您可能希望保留最近10分钟内请求响应时间的滚动窗口。每一分钟，您都要计算该窗口中值的中位数和各个百分位数，并将这些指标绘制在图表上。
简单的实现是为时间窗口内的所有请求保留一个响应时间列表，并每分钟对该列表进行排序。如果这对你来说效率太低，有一些算法可以以最小的CPU和内存成本计算出一个很好的百分位数近似值，比如前向衰减、t-digest或HdrHistogram。注意，平均百分位数，例如，降低时间分辨率或合并来自几台机器的数据，在数学上是没有意义的-聚合响应时间数据的正确方法是添加直方图。
图1-5。* 当需要多个后端调用来处理一个请求时，只需要一个缓慢的后端请求就可以减慢整个最终用户请求的速度。*