Tail Latency

• 在相关课程以及论文阅读过程中都遇到了尾延迟问题，借此机会深入学习一下
• 国内尾延迟资料相对较少，针对部分参考资料进行翻译搬运
• 埋坑，看一些尾延迟相关研究和论文，未完待续。
• btw 针对部分论文和实验中关于尾延迟的测试进行阐述

Preventing Long Tail Latency（译）

引言

• 最近，我们有一个客户跟我们求助说，他和之前的一个CDN提供商一直在努力解决延迟时间中的长尾问题。 他们有一小部分客户经历了长达30秒的加载时间，这对他们而言是“完全不能接受的”。
• 对于这个特殊的客户，降低总体平均延迟是很重要，但对他们来说更重要的是控制异常值。

什么是长尾延迟？以及是什么原因导致了长尾延迟？

• 尾部延迟总是用百分数来表示；长尾延迟指的是与平均延迟时间相比延迟的更高百分位数(例如 第98、第99)。当查看您的分析仪表板时，您可能会注意到它写着类似“每个请求，1% 的用户平均会经历一秒钟的延迟”。
• 对于服务提供商来说，缩短延迟分布的尾部可能是一个挑战，特别是对于大规模的交互式服务。由谷歌杰出工程师 Luiz André Barroso 领导的一项研究发现，系统规模越大，延迟可变性越大。当系统的规模和复杂性扩大时，服务提供商更难提供一致性。这不仅仅是随着总体使用量的增加而扩大规模的问题。譬如，当并行处理请求时，并行操作的长尾分布会立即成为一个问题，并占据整个响应时间。每个响应必须具有一致且低的延迟，否则整个操作响应时间将非常慢。高性能导致高的容忍度，这意味着您的整个系统需要按照严格的标准进行设计。
• 长尾延迟的其他原因包括:
  • 共享资源：如果机器由不同的应用程序共享，所有这些应用程序都在同一应用程序内争夺相同的共享资源(例如内存或网络带宽、处理器缓存、中央处理器内核)，不同的请求可能最终会争夺相同的资源。
  • 全局资源共享：运行在不同机器上的应用程序可能会争夺全局资源(例如共享文件系统、网络交换机)。
  • 后台守护程序：后台守护程序通常会使用特定数量的资源；然而，如果计划好了，它还是们可能会出现几毫秒的不可用状态。即使这种情况很少，但也是可能影响大规模分布式系统中的大量请求的。

长尾延迟的影响

• 为什么尾延迟比平均延迟更重要？Gil Tene 在东南电台的一个关于尾部延迟的播客中简洁地说:这是“因为人类不会感知到事件的平均结果或者平均影响；并不会因为平均水平比较高而忽略掉自己在该事件中痛苦和糟糕的经历”。
• 能够快速响应用户操作(100毫秒以内)的系统对用户来说比耗时更长的系统更自然更容易让人接受。响应是问题的关键。对于用户而言，系统响应速度的平均值较高是不够的，不足以提供好的用户体验。亚马逊开展的一项研究涉及到在账户测试中以100毫秒为增量延迟页面，即使微小的延迟也会导致收入大幅下降，代价高昂。同样，谷歌运行的一项研究显示，加载时间延迟半秒钟导致流量下降20%。
• 在 Barroso 的研究中，他用一个例子来说明尾延迟会有多长:
  • 想象一个场景，一个客户端向一个单独的网络服务器发出请求。百分之九十九的请求将在合理的时间内都会接受到对应的响应。然而，百分之一的请求的响应时间可能会很慢。如果您检查延迟的分布情况，可以发现大多数请求收到响应的延迟是小的，但是在请求分布的末尾部分可能有一个大的响应延迟。这其实倒没有什么太大的影响。这仅仅意味着每隔一段时间就会有一个客户收到稍微慢一点的回复。
  • 但是，假设您有数百万个对多个服务器的请求。现在，10K受到影响，而不是只有一个客户的响应速度较慢，这极大地改变了尾部延迟的影响。
• 使用相同的组件并扩大相应的规模会导预料不到的结果。这是可扩展系统的基本特性:高性能等于高公差。在大的规模情况下，不能忽视尾部延迟带来的影响。

如何解决长延迟？

• 完全消除导致延迟可变性问题的所有根源在大规模场景或共享环境中是不切实际的；然而，可以实现尾部延迟容忍软件技术，以帮助从不太可预测的部分中形成可预测的整体（实现尾延迟的预测）。
• 多种尾部容忍技术来解决长尾部延迟问题，包括:
  • 针对不同环境的隔离：使用容器
  • 所有容器的内存限制：防止给整个系统带来压力
  • K8S-管理数据项的多个副本的部署，并提供高可用性体系结构
  • 广播域名解析：允许域名系统查询路由到最近的数据中心，以实现快速连接域名系统连接并改进网站性能

更高层次的解决方案

• Section使用的一个更高级别的独特解决方案是以一种缩短首字节的获取时间的方式来缓存HTML。我们的竞争对手不使用同样的方法，倾向于更多地关注事物的静态资产方面。当试图消除长尾延迟时，缓存超文本标记语言是必不可少的一步。我们发现，让用户尽可能快地获得HTML是减少页面加载时间的最好方法。
• 另一种减少首字节获取时间的方法是我们通过全球边缘网络在任何地方加速 PoPs 。我们的网络目前包括北美和南美、欧洲、亚洲和澳大拉西亚的60 多个 PoPs，我们都能够按需创造新的 PoPs。
• 第三，缓慢的加载时间可以归因于第三方的资源。在 Section，我们致力于提供关于如何在页面加载事件后延迟这些资源的建议或者将第三方资源带到客户端域并缓存它们，从而保证更快的交互。
• 最后，我们始终通过部门的综合RUM数据提供关于长尾延迟的出色可视化功能，这为我们的客户提供了帮助控制长尾异常值所需的洞察力。

参考文献

• [1] 翻译原文链接：Section IO : Preventing Long Tail Latency
• [2] the morning paper：RobinHood: tail latency aware caching
• [3] Google: Taming The Long Latency Tail - When More Machines Equals Worse Results
• [4] Microsoft：Managing Tail Latency in Datacenter-Scale FileSystems Under Production Constraints