（翻译）性能监控之百分位数监控

原文链接：https://www.adfpm.com/adf-performance-monitor-monitoring-with-percentiles/

一、前言

在性能监控中什么是最好的度量—平均数还是百分位数?从统计学上讲，有很多方法可以确定应用程序提供的整体体验有多好。平均值被广泛使用。它们很容易理解和计算——但它们可能会产生误导。
这篇文章是关于百分位数的。我将解释什么是百分位数，以及如何使用它们更好地理解应用程序性能。与平均值相比，百分位数告诉我们应用程序响应时间有多一致。百分位数可以做出很好的近似，可用于趋势分析，SLA 协议监视以及每天评估/对性能进行故障排除。

服务级别协议（英语：service-level agreement，缩写 SLA）也称服务等级协议、服务水平协议，是服务提供商与客户之间定义的正式承诺。SLA的概念，对互联网公司来说就是网站服务可用性的一个保证。

平均值如何造成误导

我们可以从平均数得出错误的结论。例如:让我们假设一个国家的工人的平均月薪在 2000 美元左右(这似乎不算太坏)。然而，仔细观察我们就会发现，这个国家的大多数人都是外来务工人员，也就是 10 个人中有 9 个人是外来务工人员。他们只赚 1000 美元左右。每 10 个(当地居民)中就有 1 个月能挣11000美元左右(这太简单了，但你懂的)。如果你计算一下，你会发现这个数字的平均值确实在 2000 年左右，但我们都能理解，这并不代表一个现实的“平均”工资。这也适用于统计监控应用程序性能和监控 SLA 协议。非常高的值对平均值的影响非常大。在现实中，大多数应用程序都有一些非常重要的异常值，这些异常值对平均值的影响很大。

百分位数说明

当您想从高级角度了解应用程序的执行情况时，理解百分位数的概念是很有用的。百分位是统计中使用的一种度量，表示一组观察中某一特定百分比的观察值低于该值。例如，低于 90 %响应时间值的 HTTP 请求的响应时间称为 9 0百分位响应时间。下面的截图是 3.0 秒(所以 90 %的请求都是在 3.0 秒或更短的时间内处理的:

要获得某个单击操作的 90 %响应时间值，请按递增顺序对该单击操作发起的请求的所有响应时间值进行排序。把这一组的前 90 %拿出来。该集合中具有最大值的响应时间是单击操作请求的 90 %。

假设对于一个单击操作，有 10 个HTTP响应时间值可用:1、2、3、4、5、6、7、8、9和 10 秒。排序之后，如果我把 90 %的响应时间值作为一个单独的集合取出来，我将得到:1、2、3、4、5、6、7、8和 9。这里的 9 是最大值，因此是该点击操作的 90 %值。

当然，我们希望尽可能多的 HTTP 请求都有非常快的响应时间；所以，在一个理想的世界里，第 50、95、99 甚至是第 100 百分位的人会尽可能快。

百分比在性能监控

请看 2018 年 6月月度概述的百分位数图表(右下角):
图中用蓝色表示平均响应时间，用黑色、灰色和浅灰色绘制第 50、90 和 95 百分位数:

x 轴为 2018 年 6 月的天数，y 轴为 HTTP 响应时间(以秒为单位)。

我们可以看到以下模式：

• 第 50 百分位的响应时间大约是 1 秒(对于网页中的某个点击动作)。这意味着 50 %的 HTTP 请求在 1 秒或更短的时间内得到处理。
• 第 90 百分位大约是 2.75 秒( 90 %在 2.75 秒内处理)
• 第 95 百分位在 3.25 秒内达到最大值(95 %在 3.25 秒内处理)
• 平均响应时间大约是 2.0 秒(蓝线)。周二(6月5日、12 日、19 日和 26 日)的峰值约为 2.5 秒
• 周末的平均响应时间比工作日( 2.0 秒)低 1.6 秒。
• 我们可以看到，在周二，当平均反应时间达到峰值时，而第 50、90 和 95 百分位则更稳定。

这告诉我们什么?

• 可能有一些非常慢的请求(外围程序)对平均值有很大的影响。在这种情况下，最终用户在星期二运行许多非常慢的报告。周二是一种“报告日”，平均响应时间“混乱”。
• 这完全取决于我们的 SLA 协议以及我们的应用程序必须执行得多好。如果对于您的应用程序或 SLA 协议，有许多响应时间在2.0 到 3.25 秒之间的 HTTP 请求是可以接受的，那么您可能做得很好。然后，除了分析异常缓慢的请求( HTTP 请求中耗时超过 3.25 秒的 5 %)并确定是否可以提高它们的速度外，您无需做太多工作。
• 如果您需要在 2.0 秒内完成大多数 HTTP 请求，那么您需要做大量的工作来优化您的系统，因为如此多的请求花费的时间超过2.0 秒。

月概述-活跃用户和会话

一个关于活动终端用户和 HTTP 会话的图表——这对于评估一个托管服务器上活动的终端用户和会话数量或所有托管服务器上活动的终端用户和会话数量非常有用。稍后，我们可以将这些值性能监控图中的所有其他指标进行比较，如 JVM、SLA 协议指标、在层中花费的时间等，但现在还可以将其与百分比进行比较:

x 轴为 2018 年 6 月的天数，y 轴为活动会话数和最终用户数:

我们可以看到以下模式:

• 对于大多数终端用户和会话来说，周二是最繁忙的日子;我们在 2018 年 6 月 5 日、12日、19 日和 26 日看到峰值
• 在最繁忙的一天(6月19日)，有超过80个唯一的 HTTP 会话处于活动状态，70 个唯一的最终用户。
• 周末很少有终端用户活动(大约 10 个独立终端用户，大约 15 次会话)

趋势分析

我们可以在各种绩效评估中使用百分位数。特别是对于新版本发布后的回归和趋势分析。我们真的提高了性能吗?有时在新版本发布后性能会上升或下降——如果我们能够看到并认识到这一点将会很有用。如果是的话，第 50、90 和 95 百分位线应该在您提高生产性能后减少——这意味着更快的响应时间:

如图所示。6月17日发布了一个新的版本，据说性能有所改善。在那之后，在6月剩下的几天里，我们看到平均响应时间，第 50、90 和 95 百分位数下降了——这表明新版本确实提高了性能。

周、日、小时概述

与每月的方式相同，周、日和小时的终端用户/会话和百分比概述。以下是一个关于 Day 概述的例子:

结论

与平均值相比，百分位数告诉我们应用程序响应时间有多一致。
当平均响应时间看起来非常高，单个数据集看起来很正常时，这对于在不受异常缓慢请求影响的情况下分析性能非常有用。
百分位数非常适合用于趋势分析、SLA 协议监控和日常性能评估。