原文链接:
/news/blog/why-averages-suck-and-percentiles-are-great/
google翻译结果：
为什么平均值和百分位数都很棒
曾经监视或分析过应用程序的任何人都使用或曾经使用平均值。它们易于理解和计算。我们倾向于忽略那幅平均世界涂料的图画有多错误。为了强调这一点，让我给您一个我最近在报纸上看过的表演空间之外的真实例子。
文章解释说，欧洲某个地区的平均工资为1900欧元（很明显，这在该地区将是相当不错的！）。但是，当仔细观察时，他们发现大多数人，即十分之九的人，仅能赚到1000欧元左右，而一个人却能赚到10.000欧元（我当然简化了，但您明白了）。如果您做数学运算，您会发现平均工资确实是1900，但是我们都可以同意这并不代表“平均”工资，因为我们会在日常生活中使用这个词。因此，现在让我们将此思想应用于应用程序性能。
平均响应时间
到目前为止，平均响应时间是应用程序性能管理中最常用的指标。我们假定这代表一个“正常”事务，但是，只有在响应时间始终相同（所有事务以相同的速度运行）或响应时间分布大致呈钟形时，这才是正确的。
贝尔曲线代表响应时间的“正态”分布，其中平均值和中位数相同。我很少出现在实际应用中
在贝尔曲线中，平均值（中位数）和中位数相同。换句话说，观察到的绩效将代表交易的大部分（一半或一半以上）。
实际上，大多数应用程序的异常值很少。统计人员会说曲线长尾巴。长长的尾巴并不意味着很多缓慢的交易，但是很少有比正常交易速度慢的交易。
这是典型的响应时间分布，离群值很少但很重-尾巴很长。此处的平均值被长尾巴拖到右侧。
我们认识到，平均值不再代表交易的大部分，而是可以比中位数高很多。
现在，您可以辩称，只要平均值看起来不比中位数好，这不是问题。我不同意，但是让我们看一下我们许多客户遇到的另一种现实情况：
这是另一个典型的响应时间分布。在这里，我们有很多非常快的交易将平均值拖到实际中位数的左侧
在这种情况下，相当大比例的事务非常非常快（10％到20％），而大部分事务却慢了好几倍。中位数仍然可以告诉我们真实的情况，但是突然之间的平均值看上去比我们大多数交易实际上要快得多。这在搜索引擎中非常典型，或者在涉及到缓存时，某些事务处理非常快，但大部分操作是正常的。这种情况的另一个原因是交易失败，尤其是交易失败很快的交易。由于用户错误或验证错误，许多实际应用程序的故障率均为1-10％。这些失败的交易通常比真实的交易快几个数量级，因此平均水平失真。
当然，性能分析师并不愚蠢，而是定期尝试使用较高频率的图表进行补偿（通过肉眼观察较小的聚合来进行补偿），并采用最小和最大的观察响应时间。但是，通常只有在非常了解应用程序的情况下才能执行此操作，那些不熟悉应用程序的人可能会容易误解图表。由于所需的知识的深度和类型，很难将您的分析结果传达给其他人–考虑一下IT团队之间有多少争论。那是在我们甚至考虑与业务利益相关者进行沟通之前！
到目前为止，更好的指标是百分位数，因为它们使我们能够了解分布。但是在研究百分位数之前，让我们看一下每个生产监视解决方案中的关键功能：自动基线和警报。
自动基准和警报
在现实环境中，性能很差时会引起注意，并且会对业务和用户产生负面影响。但是，我们如何快速识别性能问题以防止负面影响？由于总是有一些交易，因此我们无法提醒每笔缓慢的交易。此外，大多数运营团队必须维护大量不熟悉所有应用程序的应用程序，因此手动设置阈值可能不准确，非常痛苦且耗时。
业界提出了一种称为自动基准的解决方案。基准计算可以计算出“正常”性能，并且仅在应用程序运行速度变慢或产生比平常更多的错误时提醒我们。大多数方法依赖于平均值和标准偏差。
在不涉及统计细节的情况下，该方法再次假设响应时间分布在钟形曲线上：
标准差代表所有交易的33％，平均值为中间值。2xStandard Deviation代表66％，因此大多数情况下，外部的一切都可以视为异常值。但是，大多数现实情况并非一帆风顺。
通常，超出标准偏差2倍的交易将被视为缓慢并捕获以进行分析。如果平均值发生明显变化，则会发出警报。在钟形曲线中，这将占最慢的16.5％（您当然可以对其进行调整），但是，如果响应时间分布不代表钟形曲线，则它会变得不准确。我们要么以许多误报为最终结果（比平均速度慢很多的交易，但当看曲线处于标准范围之内），或者我们错过了很多问题（误报）。此外，如果该曲线不是钟形曲线，则平均值可能与中位数相差很大，对此类平均值应用标准偏差可能会导致与您预期的结果完全不同！
为什么我爱百分位数
一个百分位数告诉我正在查看曲线的哪一部分以及该度量代表多少笔交易。要形象地看一下下面的图表：
该图表显示了第50个百分点和第90个百分点以及同一笔交易的平均值。它表明，平均值受到第90个因素的影响更大，因此受异常值的影响较大，而不受交易总量的影响较大
绿线代表平均值。如您所见，它非常不稳定。另两个线表示50 个和90 个百分位数。如我们所见，第50 个百分位数（或中位数）相当稳定，但有几次跳跃。这些跳跃表示大多数交易（50％）的实际性能下降。第90 个百分位数（这是“尾巴”的开始）更加不稳定，这意味着异常值的缓慢程度取决于数据或用户行为。重要的是，平均值受到第90 个百分位，尾部而不是大部分交易的影响（拖累）。
如果响应时间的第 50 个百分位数（中位数）为500毫秒，则意味着我的交易的50％比500毫秒快或快。如果同一笔交易的第 90 个百分位数是1000毫秒，则意味着90％的速度或快或慢，只有10％的速度或快。在这种情况下，平均值可能低于500ms（在较重的前曲线上），更高（较长的尾巴）或介于两者之间。百分位数使我对现实世界的表现有了更好的了解，因为它向我展示了我的响应时间曲线的一部分。
正是由于这个原因，百分位非常适合自动基线。如果第50个百分位数从500毫秒变为600毫秒，我知道50％的事务性能会下降20％。您需要对此做出反应。
在许多情况下，我们看到在这种情况下，第75或第90个百分位数根本没有改变。这意味着缓慢的交易不会变慢，只有普通的交易会变慢。在这种情况下，平均值可能根本没有移动，具体取决于您的尾巴有多长！
在其他情况下，我们看到第98个百分位数从1秒降为1.5秒，而第95个百分位数稳定在900毫秒。这意味着您的应用程序总体上是稳定的，但是一些异常值变得更糟，无需立即担心。基于百分位数的警报不会遭受误报，波动性要小得多，并且不会错过任何重要的性能下降！因此，使用百分位数的基线方法不需要大量调整变量即可有效工作。
下面的屏幕截图显示了特定事务的中位数（第 50 个百分位数）从约50ms跳到约500ms，并触发了警报，因为该警报显着高于计算的基线（绿线）。另一方面，标有“响应时间慢”的图表显示了同一笔交易的第 90 个百分点。这些“异常值”还显示了响应时间的增加，但不足以触发警报。
在这里，我们看到了一个自动基准基线仪表板，在第50个百分位数处存在违规情况。违规行为很明显，同时第90个百分位（右上图）没有违反。因为离群值比交易的总体速度慢得多，所以平均数会受到它们的影响，并且反应不会像第50个百分位数那样剧烈。我们可能错过了这种明显的违反！
我们如何使用百分位数进行调整？
百分位数也非常适合调优，并为您的优化提供特定目标。假设我的应用程序中的某些内容通常太慢，我需要使其更快。在这种情况下，我想集中精力降低第90个百分点。这将确保应用程序的总响应时间减少。在其他情况下，我的异常值太长了，我想集中精力降低响应时间，使其超出第98个或第99个百分点（仅异常值）。我们看到许多应用程序对于第90个百分位数具有完全可接受的性能，而第98个百分位数的性能更差。
另一方面，在面向吞吐量的应用程序中，我希望非常快地完成大部分事务，同时接受优化会使一些异常值变慢的事实。因此，我可能会确保尝试保持第90个百分位数稳定或不会变得更糟的同时降低第75个百分位数。
我无法用平均值，最小值和最大值进行相同类型的观察，但是使用百分位数确实很容易。
结论
平均值过于简单和一维，因此无效。百分位数是理解应用程序实际性能特征的一种非常简便的方法。它们也为自动基线，行为学习和正确关注应用程序优化提供了良好的基础。简而言之，百分位数很棒！