亚马逊AWS官方博客
互联网性能观测 – 容易被忽视的几个指标
在您通过亚马逊云科技提供互联网服务的旅程中，用户的访问体验对您的应用至关重要，但来自互联网的不可预知性会对用户访问的体验产生不确定性。互联网性能观测是我们运营互联网服务的一个重要的组成部分，通过收集来自客户端和服务端以及第三方的数据，描绘出用户通过互联网访问云上应用的网络层感受群体画像，如首包时延 / 下载时长 / 成功率，细化为多个维度的指标，如按国家 / 按时间 / 按终端类型 / 按访问对象 / 按访问路径。在指标维度上，我们也经常使用平均值 / P50 / P90 / P99 档位来进行指标细分，除了这些指标外，本文会分享另外几个容易被忽视但是比较有意义的指标，另外也会介绍在数据采集/指标计算/指标展现阶段使用到的相关服务，包括 Amazon Athena 和 Amazon SageMaker 服务。
Trim 指标
在互联网中，个别用户会经历过长时间的等待，这些用户的性能数据可能会影响整体的平均值，比如我们采集到了 100 个用户下载时长的数据：99 个数据点都在 0.8s – 1.0s 的区间内，平均值是 0.9s；但有 1 个数据点在 100s，这 100 个样本数据的平均值劣化为 (99*0.9+1*100) / 100= 1.9s。很明显这个 100s 的数据点影响了整体的平均值，对观测产生了干扰。Trim 指标可以帮助我们屏蔽这些干扰。
Trim 指标包含了 TM/TS/TC 3 个类型的指标，TM（Trimmed mean）表示“去除一定比例的最低值，去除一定比例的最高值”后，来观察实际平均值，通常写为 TM（1%:99%）。TS（Trimmed sum）和 TM 类似，表示“去除一定比例的最低值和最高值后数据指标总和”；TC（Trimmed count）表示““去除设定最低值和最高值后数据指标项的计数”，通常表示为 TC（2:200）。
如果我们想观测某个网页的整体首包时延，P50 / P90 / P99 指标展现了 3 位典型用户的感受；TM99 和平均值展现的是群体用户的感受，并且 TM99 去除了干扰，比平均值更加接近实际的整体感受。下面是一个例子。
通过 Amazon CloudFront 日志文件采集了 1.5 亿条首包时延的数据集，使用 Amazon SageMaker Notebook 运行 Python，引入 Python Pandas 和 scipy 工具进行统计（代码链接），结果如下：
 |
我们观察到首包时延 p99 位于 0.408 秒，平均值位于 18 毫秒；在去除了高于 0.408 秒的数据点之后，tm99 值为 13 毫秒；可以更为准确的反应用户的普遍感受。
箱位指标
Trim 指标中的 TC 值（Trimmed count）表示“去除设定最低值和最高值后数据指标项的计数”，它初步揭示了数据的分布。和 TC 值类似的另一个指标是 PR（Percentile Rank），表示“去除设定最低值和最高值后数据指标项的计数比例”，更有有实际意义的指标。比如我们获取了一组用户首包时延的数据，想了解首包时延低于 1 秒（较佳的用户感受）的用户数占整个用户群体的比例，PR 值可以为我们提供这个观测指标。我们还是以包含了上一章节 Amazon CloudFront 日志文件采集的 1.5 亿条首包时延的数据集为例（代码链接）：
 |
小于 1s 首包时延的用户访问占据了 99.97% 的比例，对于一般的网页访问来说，已经是一个不错的用户感受统计值了。
直方图
TM 指标和箱位指标为我们展现了用户感受的另一个侧面，我们可以将这 2 个指标结合传统的均值 / P50 / P99 指标描绘出更加完整的用户感受。但统计值本身毕竟会丢失一些数据，给我们在互联网观测上产生错觉，如下面这个例子。
假设我们观测到了首包时延的 P50 和 P90 值，我们认为的数据分布应该是这样的（正态分布）：
 |
但实际上的数据分布是这样的：
 |
虽然 TM 和 PR 观测值也可以让我们了解数据的分布，但毕竟不如图形来的直观。在看到上图的时候，我们是不是会把调优的关注点从降低 P90 / P99 值转移到减少 P90 区间的数据点数量上来？直方图是一个描绘数据分布的观测方法，可以给到我们观察者更完整的信息，它揭示了数据中缺失的一大部分内容 — 非正态分布下的数据分布。
我们还是以前 2 章使用的数据集为例，加入 Python 的 matplotlib 库来实现直方图的展现（代码链接），首先来看数据分布：
 |
从直方图中我们看到绝大部分的首包时延数据点集中在 1ms-20ms 区间内，相比于 TM99 / P50 / P90 / P95值是不是更加直观？结合实际情况，这张直方图也说明了大部份的用户访问得到了 CloudFront 缓存的加速。
让我们将数据做一个过滤，看一下未被 CloudFront 缓存的数据点的分布，从而观察源站的首包时延（代码链接）：
 |
从这张直方图中我们看到首包时延的数据点集中在 2 个区域 — 50ms～150ms 区域和 300ms～450ms 区域，并不是正态分布，我们的优化目标就可以细化为降低 300ms～450ms 区域的数据点数量；相比于降低 P95 / P99 值来的更加有实践意义。
Amazon Athena 和 SageMaker Notebook 服务
在本文的代码中，我们使用了 Amazon Athena 服务进行 Amazon CloudFront 日志的收集，Amazon Athena 对 Amazon CloudFront 日志文件进行了标准化和裁剪的 ETL 工作。Amazon SageMaker Notebook 服务为本代码提供了 IDE 环境，可以方便地引用 Amazon boto3 SDK 通过 Python 来调用 Amazon Athena 服务。
总结
互联网的不可预知性为我们提升来自互联网的用户访问感受带来了困难，通过科学的数据观测方法和适当的工具可以帮助我们看到全貌并从中发现规律，为调优奠定基础。相比在 P99 层面降低 1ms 时延，降低 P90 数据点的分布更为有实际意义。Trim 指标 / 箱位指标 / 直方图都是可以帮助到我们观测互联网用户感受的工具。Amazon CloudWatch 指标中也增加了 Trim 指标和箱位（PR）指标（参见链接）。
 |