本文主要是介绍Treadmill: Attributing the Source of Tail Latency through Precise Load Testing and Statistical Infer，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
题目：
Treadmill:通过精确的负载测试和统计推理识别尾延迟来源
摘要
管理请求的尾部延迟已经成为大规模Internet服务的主要挑战之一。 数据中心正在快速发展，服务运营商经常希望对部署的软件和生产硬件配置进行更改。 这种变化需要对对服务的影响，特别是其对尾部延迟的影响（例如，服务的响应延迟的95％或99％）的理解。 评估对尾部的影响是具有挑战性的，因为其固有的变异性。用于测量这些影响的现有工具和方法存在许多缺陷，包括差的负载测试仪设计，统计上不准确的聚合和不正确的效应归因。 如文中所示，这些陷阱常常会导致误导性的结论。
在本文中，我们为服务器工作负载开发统计性严格的性能评估和性能因素归因的方法。首先，我们发现服务器负载测试器的仔细设计可以确保高质量的性能评估，并且经验性地证明了负载测试人员在以前的工作中的不准确性。从先前的工作中学习设计，我们设计和开发了一个模块化负载测试平台，跑步机，克服了现有工具的缺陷。接下来，利用跑步机，我们构建可以适当归因于性能因素的测量和分析程序。我们依靠统计学上的性能评估和分位数回归，将其扩展到适应服务器系统的特性。最后，我们使用增强的方法来评估通用服务器硬件功能与生产硬件上的Facebook生产负载的影响。我们根据请求尾部延迟分解这些特征的影响，并表明我们的评估方法提供了优异的结果，特别是在捕获复杂和反直觉的性能行为方面。通过调整归因建议的硬件特性，我们将第99百分位数延迟减少了43％，差异减少了93％。
前言
减少尾部延迟（即延迟分布的高分位数）提高了大规模互联网服务的服务质量[1]。 高尾延迟已被确定为现代数据中心设计面临的主要挑战之一，因为它导致用户体验不佳，特别是对于诸如网络搜索和社交网络之类的交互式服务。这些服务由机群集群供电，其中单个请求以“扇出”模式分布在大量服务器之间。 在这种设计中，这种系统的整体性能取决于响应速度最慢的机器[2]。 最近的工作试图控制和理解这些尾部请求，无论是在个别服务器还是整个集群级别[3]。
对于数据中心运营商来说，精确测量尾部延迟而不会中断生产系统的能力很重要，原因有很多。首先，服务器通常大量（例如每次1000s）获取，因此选择最佳设计并仔细提供资源很重要。 评估硬件配置需要对提高的工作负载进行大量和准确的测量。第二，有必要在不破坏生产系统的情况下，忠实地测量效能。 软件和硬件变化的高频率使得评估这些生产变化非常困难或不可能，因为它可以很容易地导致用户可见的事件。 相反，最好在安全但准确的负载测试环境中了解性能关键决定的影响。
构建这样的负载测试环境以实现精确的尾部延迟测量是特别具有挑战性的。这主要是因为与传统的单服务器工作负载（例如SPEC CPU2006，PARSEC）相比，大规模Internet服务工作负载（例如，分布式服务器端软件，网络连接等）所涉及的系统和资源显着增加。 尽管已经有几个以前的工作[4,5,6,7,8,9,10]试图弥合这个差距，但是在他们的负载测试设计中有几个陷阱，我们将在后面的文章中给出。 不幸的是，这些工具通常用于研究出版物进行评估，陷阱可能导致误导性的结论。类似于学术界，工业界还缺乏准确的尾部延迟测量测试台，导致不必要的资源过度供应[11]和不明原因的性能回归[12]。
此外，为了能够控制这些互联网服务的尾部延迟，需要彻底和正确地理解尾部延迟的来源。这些互联网服务与广泛的系统和资源（包括操作系统，网络堆栈和服务器硬件）进行交互，从而定量地将尾部延迟来源归因于个人资源的能力是至关重要的。 虽然以前的一些作品[13,14,15,16,3,17,18,19,20,21,22,23,24,25]研究了个别资源对尾部潜伏期的影响，但许多资源复杂的相互作用行为，无法在孤立的研究中被捕获。 例如，Turbo Boost和DVFS调速器可以通过竞争热余量来间接地相互作用。 请注意，识别尾部延迟源的能力取决于上述第一个挑战。
换句话说，没有对尾部延迟的精确测量，我们将无法将其正确归因于各种来源。在本文中，我们首先调查研究界使用的现有绩效评估方法。 我们已经确定了这些工具的一组常见错误：
•查询到达后生成 - 负载测试软件通常用于简化软件。 我们发现常用的编程范例创建一个隐式排队模型，其近似于闭环系统，并且系统地低估了尾部延迟。相反，我们展示了精确定时的开环负载测试仪是正确运行系统排队行为所必需的。
•统计汇总 - 由于请求率高，必须采用采样来控制测量开销。必须仔细执行这些延迟样本的在线聚合。我们发现，单数统计（例如，第95或99个周期延迟的点估计）不能捕获详细信息;其他负载测试仪中使用的静态直方图也表现出偏差。
•客户端排队偏差 - 由于许多商业系统中的高吞吐率（每秒100k-1M的请求），我们证明，必须使用多台客户机来测试单个服务器。没有使用轻松的客户端，延迟测量迅速开始受到客户端排队的影响，产生有偏见的结果。
•性能“滞后” - 我们观察到在收集足够数量的样本之后估计的延迟收敛的现象，但是在再次运行负载测试时，测试收敛到不同的值。这是由于底层系统状态的变化，如逻辑内存，线程和连接到物理资源的映射。我们将其称为滞后，因为没有合理数量的附加样本可以使两个运行收敛到同一点。相反，我们发现实验必须重新启动多次，并且收敛的值应该被聚合。
基于这些见解，本文提出了一种用于精确尾部延迟测量的系统过程，并详细说明了设计选择，使我们能够克服现有方法的缺陷。提出的程序利用模块化软件负载测试仪Treadmill的多个轻量级实例，以避免客户端排队偏差。Treadmill的软件架构保留正确的请求到达之外的时间，并且允许轻松添加新的工作负载，而无需复杂的软件更改。重要的是，它可以适当地聚合客户端的分布，并执行多个独立的实验来减轻性能滞后的影响。
通过Treadmill实现的精确测量使得能够识别延迟来自哪里。我们基于最近的分位数回归研究[26]，并将尾部延迟归因于导致尾部的各种硬件特征。这允许我们公布系统“黑盒子”，并更好地了解调整硬件配置对尾部延迟的影响。我们使用运行两个关键Facebook工作负载的Facebook生产硬件进行此评估：普及密钥服务器Memcached和最近公布的软件路由系统mcrouter [27]。使用我们的尾部延迟归因程序，我们能够识别许多反直觉的性能行为，包括不同硬件资源之间的复杂交互，这些交互不能通过孤立的各个硬件功能的先前研究来捕获。最后，我们展示了我们成功捕获了mcrouter系统中90％的性能变化，并为Memcached捕获了95％以上的性能变化。通过仔细调整归因建议的硬件功能，我们将第99百分位数延迟减少了43％，方差99位的百分比减少了93％。
总之，本文有三个主要贡献：
•对现有负荷测试方法中常见的陷阱进行调查 - 对相关工作现有方法进行调查，并对其缺点进行实证分析。我们将这些镜子分类为未来从业人员的四大原则。
•精确的基于群集的绩效评估方法 - 我们介绍了一个强大的实验方法的设计，以及作为开源软件发布的软件负载测试工具跑步机。这两个系统都符合我们原则的要求，并且易于扩展以供采纳。
•归因于尾部延迟的来源 - 通过我们的方法实现的高精度测量使得可以使用分位数回归来理解尾部延迟方差的来源。我们成功地将大部分方差归因于几个高级硬件特征及其间的相互作用。通过仔细调整归因结果推荐的硬件配置，我们显着降低了尾部延迟及其差异。
现代艺术方法论中的讽刺
为了了解评估试验台的要求，我们首先调查了以前工作中现有的方法和工具。许多工具可用于研究服务器端软件的性能，包括YCSB [4]，Faban[28]，Mutilate [29]和CloudSuite[6]。 这些工具已经广泛应用于标准的基准套件，包括SPEC2010 jEnterprise [30]，SPEC2011 SIP基础设施[31]，CloudSuite [6]和BigDataBench [8]，从而引起了许多最近发表的研究项目。
通过研究这些现有工具，我们发现了几个常见的陷阱。我们将它们分为以下四个主题。
A.查询到达后生成
性能评估测试台需要一个负载测试器，一个以受控的方式向服务器发出请求的软件。客户机将运行负载测试器，周期性地构建，发送和接收请求以实现期望的吞吐量。通常采用两种类型的控制回路来创建这些定时：开环控制和闭环控制[32]。闭环控制器具有反馈回路，其中仅在已经接收到对先前请求的响应之后才尝试发送另一个请求。相比之下，开环控制器在定义的时间内发送请求，而不管响应的状态如何。几乎所有的现代数据中心服务器端软件都是为了处理开环设置而建立的，所以每个服务器线程在忙碌处理之前都不会拒绝来自客户端的请求。
然而，由于软件的简单性，许多负载测试仪被实现为闭环控制器，包括Faban，YCSB和Mutilate，如表I所示。通常，使用发出网络请求时阻止的工作线程生成负载。然后可以通过增加或减少负载发生器中的螺纹量来控制负载量。不幸的是，这种模式完全类似于闭环控制器;每个线程正好代表一个潜在未完成的请求
B.统计汇总
由于请求率高，负载测试软件需要至少执行一些延迟样本的统计汇总，以避免保持大量样本的开销。我们发现在这个过程中必须小心，可能会发生两种类型的错误。首先，负载测试人员必须保持随时间变化的延迟内部直方图。那些维护直方图的负载测试仪常常会导致静态设置直方图桶的错误。当服务器被高度利用时，非自适应直方图分组将会中断，因为延迟在达到稳定状态之前会保持增加，从而超过直方图的上限。
此外，如果请求具有不同的特征（例如，不同的请求类型，由不同的机器发送等），我们观察到由于不正确的统计聚合而可能发生偏差。例如，在图2中，我们演示了一种场景，其中四个客户端用于将请求发送到同一个Memcached服务器，“客户端1”位于与其他客户端和服务器不同的机架上。在x轴上的每个延迟点，每个阴影区域表示来自四个客户端之一的样本的比例。随着分数量的增加，人们可以清楚地看到，大多数样本来自“客户端1”。这种偏差是有问题的，因为系统的性能估计成为一个单一客户端的功能。相反，应该单独提取每个客户端的感兴趣度量（例如，第99百分位数延迟），并将其合理聚合。
C.客户端排队偏差
在操作负载测试器时，纯粹测量服务器端延迟的影响很重要。对于服务时间长（例如，复杂的MySQL查询）的工作负载，客户端不必发出许多使服务器饱和的请求。然而，对于像Memcached这样的工作负载，客户端和网络本身的请求率相当高。这可能导致客户端和网络本身的排队效应，从而偏差延迟测量。 YCSB和CloudSuite由于其单个客户端配置而受到这样的偏见，如表I所示。
图3显示了客户端和网络利用率如何对延迟测量进行偏差的示例。在“单客户端安装”中，客户端和网络具有与服务器相同的利用率。可以看出，客户端延迟和网络延迟随着服务器利用率的增加而增长，并且在端对端延迟中占有重要的比例。
我们发现设计一个可以使服务器充分饱和的单客户端负载测试器是非常具有挑战性的，即使不是不可能，也不会对以微秒级延迟运行的现代数据中心工作负载造成重大的客户端排队。相反，有必要建立一个多客户机，并且拥有足够数量的机器，使得客户端和网络延迟保持较低。在“MultiClient Setup”中，我们增加了客户端计算机的数量以最小化这些偏差。经过调整后，大部分测量的延迟来自服务器。
D.性能“迟滞”
图4.差异存在，而不管单个运行的样本大小。单次运行对于小样本量（即，运行早期）表现出很大的变化。具有足够大的样本量，第99百分位数延迟的估计收敛。 然而，从经验上我们发现每个运行都可以收敛到一个不同的值。 虽然每次运行的测试程序都会产生紧密的间隔，每次运行的结果明显变化（与平均值相差15-67％）。
通过实验，我们发现一个通常的行为，如何估计收敛，我们称之为性能“迟滞”。图4表明，随着更多样本的收集，第99百分位延迟的估计开始收敛到一个奇异值。但是，如果重新启动服务器并执行另一个运行，则估计可以收敛到不同的值。
在这种情况下，估计的样本量很大，我们预计每个估计值的“确定”都很高，但显然在运行中仍然存在差异。事实上，这些估计与平均值的差异高达67％。这种现象意味着只能通过“运行更长时间”来实现更高的统计准确度，并且与STABILIZER[33]中观察到的效果相似。相反，有必要多次重新启动整个过程并聚合结果。然而，现有的负载测试仪都没有足够的足够强大来处理这种情况，如表I所示。
注：内容太多，只有1、2章节，我的操作系统课程作业。
这篇关于Treadmill: Attributing the Source of Tail Latency through Precise Load Testing and Statistical Infer的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
