砂纸：CDN边缘性能干扰缓解

砂纸：缓解内容分发网络边缘代理中的性能干扰

摘要

现代内容分发网络（CDN）允许其客户（即网络服务运营商）通过在CDN网络边缘上传和执行代码来自定义请求处理。为了实现规模化，CDN已放弃重量级虚拟化技术，而是让所有请求通常在同一操作系统甚至同进程中执行。然而，当这些请求对多种系统资源的需求不同时，可能会产生性能干扰。本文基于真实客户的工作负载研究性能干扰的来源，指出多资源公平性的缺失是根本原因，并表明通用操作系统中现有的调度器不足以在客户之间实施公平性。

然后，我们设计了砂纸（Sandpaper），这是一种新颖且实用的多资源请求调度器，用于缓解CDN边缘环境中的性能干扰。尽管存在诸如位于应用程序运行时内部以及在操作系统底层资源调度器之上运行等限制，砂纸仍能实现公平性。通过利用关于理论系统模型与实际系统之间差异的关键洞察，砂纸弥合了现有调度器所面临的资源利用率与多资源公平性之间的权衡问题。我们在Varnish这一开源CDN边缘代理之上实现了砂纸，并表明其在保持高资源利用率的同时，能够有效缓解性能干扰且仅带来轻微的性能开销。

1 引言

如今，许多内容分发网络在它们的网络边缘提供可定制的计算环境[1, 2, 9, 11, 14, 16]。客户利用这些可编程环境来改进其服务，例如通过为用户定制内容。

其中一些服务，例如Fastly和SFR电信，基于Varnish（一个开源HTTP反向代理[1, 2, 7, 14]）构建。通过Varnish，它们使客户（如《纽约时报》等服务）能够使用高级领域特定语言Varnish配置语言（VCL），在他们网络的边缘自定义请求处理。其他内容分发网络（CDN），如Cloudflare Workers[16]和CloudFront的Lambda@Edge[11],，也提供类似功能。

这些新的多租户边缘平台为数以万计的客户提供服务，峰值负载高达每秒数千万次请求[1, 14, 20]。单个进程中的多个线程处理来自不同客户的请求，在硬件和软件资源上进行细粒度共享，且不使用虚拟化技术[14, 16]。基于真实客户的工作负载，我们证明了当客户同时向这些平台提交请求时，可能会经历显著的性能干扰。

通过对多种系统资源上请求处理瓶颈的分析，我们发现性能干扰问题源于请求对多种资源的不同需求。因此，必须通过实施客户之间的多资源公平性[37]来解决该问题。

2 相关工作

内容分发网络

内容分发网络（CDN）于20世纪90年代出现，旨在提高Web性能[53, 58, 64]。CDN在互联网边缘部署服务器，以缓存静态内容，降低用户请求的延迟，并减少Web服务运营商的带宽和基础设施需求[25, 31]。随着Web内容变得越来越动态，CDN边缘服务器发展为按需动态生成内容的能力[31, 46, 58, 64]。随着时间的推移，这些功能演变为可编程环境，允许运营商通过在CDN服务器上部署代码来修改请求处理[9, 11, 14, 16]。

操作员代码最初是用受限的编程语言[7, 10]编写的。然而，物联网和移动计算进一步推动了这一趋势，诸如语音识别等任意且计算密集型的任务被卸载到靠近用户的称为云微端的小型数据中心[35, 51, 52, 57, 58]。我们在此关注的是一个更为受限的可编程边缘环境[7]，但我们认为本文提出的CDN客户之间的性能干扰问题同样适用于云微端等更通用的环境。

CDN服务质量

由于内容分发网络的广泛采用，其性能得到了深入研究[18, 19, 24,45, 56]。研究人员已开发出多种技术来提升内容分发网络的性能。在整体层面，已研究了负载均衡[25, 45, 53],、最优服务器部署[42, 47, 55],和复制[27, 43, 62]。在单个服务器上，先前的研究通过多个角度探讨了服务质量，包括控制理论[17],、资源供给[26, 63],、基于模型的方法[32],、实时内核扩展[50],和公平排队[29, 40, 44, 54, 61]。这些研究在希望改进的指标方面也各不相同。本文中，我们利用多资源公平队列[36]框架来改善单个内容分发网络服务器中的公平性。

多资源公平队列

多资源公平性（MRF），也称为主导资源公平性，是最大最小公平性在多种资源类型上的推广[36, 37]。公平排队调度器最初是为了在共享单一资源的一组流之间实现最大最小公平性而设计的[29, 54],，并已提出了大量算法[29, 40, 44, 54, 61]。这些算法在公平性的最坏情况界限、请求延迟的最坏情况界限以及计算开销之间进行权衡。

多资源公平队列（MRFQ）[36]首次将一种公平排队算法[40],扩展到多种资源。自那以后，更多MRFQ调度器被开发出来[36, 68ś70]。然而，这些进展在很大程度上是理论的；这些算法要么对底层系统做出不切实际的假设[36, 69]，要么如我们所展示的那样，存在未充分利用并行系统资源（例如多核CPU）的风险。

[68, 70],使得它们不切实际。一个例外是李和钱[48],，该研究专注于通过sketching方法降低Ghodsi等人[36]的开销。王等人研究了多资源公平性与资源利用率之间的权衡，无论是在理论[67]上还是在存储系统[66]中。然而，与其他为数据中心开发的多资源调度算法[23, 28, 38,65],一样，后者并不直接适用于我们的场景，因为我们的系统必须做出在线调度决策。

新的内核API

Banga等人提出了一种新的系统调用接口，用于解耦线程和资源监控抽象[21]。然而，部署自定义的内核修改会带来可移植性和可维护性方面的问题[49]。为了保持砂纸的实用性，我们因此避免要求对底层操作系统进行更改。

3 动机

3.1 内容分发网络边缘的可编程性

图1展示了基于Varnish[7], 构建的可编程内容分发网络边缘环境的概览，该环境是多个内容分发网络[1, 2, 14]的核心。这些Varnish实例共同为全球的客户端（即终端用户）提供HTTP请求服务。例如，Fastly 40+ 的节点位置平均每秒处理超过700万次请求[20]。本文重点关注部署在单个服务器上的单个Varnish实例，该实例必须每秒处理数万个请求。

在Varnish中，一个工作线程池处理HTTP请求。所有请求都在单个进程中执行。

1: 导入 geoip2；
2: 函数vcl init_
3: setcountryCodeMap = geoip2.load(ł/lib/country.mmdbž);
4: 函数vcl recv_
5: 设置 req.http.CC = countryCodeMap.lookup(client.ip);
6: 返回(hash);
7: 函数vcl hash_
8: 追加_到_hash_key(req.http.CC);

图2：用于缓存网页多个位置特定副本的VCL示例[7]。

为便于说明，其语法与真正的VCL略有不同。

工作线程接受新的TCP连接；该接收线程按先进先出顺序将新请求交给其他工作线程，由它们完成处理。对于每个请求，工作线程解析其头部和负载，加载并执行相应运营商的代码（使用请求的Host头部），组装响应（来自缓存或通过联系源服务器），并将响应传输给用户。其他内容分发网络使用类似的架构[11, 16]。

Web服务运营商通过向Varnish上传代码来自定义其请求处理过程。该代码使用Varnish配置语言（VCL）编写。每个运营商在逻辑上维持一个单独的VCL。函数被编译后链接到Varnish的运行时，并在请求处理过程中特定的钩子处被调用。图2展示了一个VCL示例，它使Varnish将网站的位置特定副本作为独立对象进行缓存，从而允许用户查看与其位置相关的内容。vcl init和vcl recv分别在VCL首次加载以及Varnish首次接收到每个请求时运行。第5行使用客户端IP地址查询本地国家代码数据库。该查找结果存储在一个新的请求头CC中。第6行指示Varnish接下来计算其哈希函数以进行缓存查找。第7‐8行定义的哈希函数在计算缓存键时，除了默认头部外，还将新的CC头部包含在内。

3.2 异构资源需求导致性能干扰

在单个进程中执行来自不同客户的代码可能会因系统资源的细粒度共享而导致性能干扰。当一个客户的工作负载发生变化（例如上传新的VCL）时，会不公平地影响到另一个客户的请求性能（延迟或吞吐量），从而引发性能干扰。在本节中，我们展示了Varnish中存在的显著吞吐量干扰，并证明其原因是异构资源需求。我们将在后续评估延迟（ğ6.2）。

首先，我们为四个数字出版服务构建模拟VCLs，这些服务是某主要内容分发网络的已知客户。每个VCL都使用其客户评价中提到的功能[3ś6]。以下是每个所采用功能的摘要

客户	功能	CPU处理	客户端 网络传输
C1	在文章链接旁插入相对发布时间戳	39.88 (1.96)	22.08 (0.001)
C2	将请求和响应头记录到Linux系统日志中 验证JSON Web令牌以实现内容个性化	13.60 (0.88)	81.25 (0.01)
C3	针对设备优化内容的用户代理头规范化。 在头部添加地理IP信息以提供位置特定的内容。	28.10 (1.19)	92.18 (0.001)
C4	嵌入包含实时直播内容的JSON对象。	22.81 (0.99)	36.40 (0.001)

表1：4个模拟CDN客户使用的功能及其对客户端请求到客户站点时产生的CPU和网络处理时间（单位为微秒）。处理时间的标准差显示在括号中。下方将对这些功能进行更详细的说明，并精确定义处理时间。

客户如表1所示。客户C1使用VCL在其页面的文章链接旁插入相对发布时间戳，例如“5分钟前发布”。客户C2使用VCL根据用户权限向用户展示不同的内容。客户C3使用VCL将网站的位置特定副本作为独立对象进行缓存，并针对用户的设备优化这些副本。最后，客户C4使用VCL为其实时博客页面提供支持，确保用户始终加载最新的博客内容。我们还抓取了每位客户的网页副本。此后，我们将VCL和网页的组合称为customer。请注意，增加更多客户只会放大此处所展示的性能干扰可能性。

为了测量客户c1和c2, 之间的性能干扰，我们使用一个闭环[60]客户端[39]，每个客户使用100个线程来测量其归一化吞吐量μc1,c2/μc1，其中μc1,c2表示当c1和c1的请求在Varnish中竞争系统资源时，c2的平均吞吐量，而μc1是c1在独立运行时的平均吞吐量。在一个公平的单资源系统中，我们期望每个客户的归一化吞吐量为0.5；此时资源上的处理将在这两个客户之间平均分配。在一个公平的多资源系统中，它们的归一化吞吐量相等，但可能大于0.5，因为异构资源需求可能导致总吞吐量增加。

远未实现一个公平的系统，图3显示在Varnish中某些客户受到了不公平的对待。对于每一对比较，我们绘制了两个归一化吞吐量中较小值与较大值的比值。在最极端的情况下，C3与C4比较，归一化吞吐量分别为0.68和0.31；客户C3的吞吐量仅下降了32%，而客户C4的吞吐量则下降了69%。此外，客户C1的吞吐量下降幅度明显大于其他客户；在C1与C2、C1与C3、C1与C4的比较中，归一化吞吐量分别为0.62和0.72；0.55和0.74；以及0.50和0.61。ğ6包含了有关实验设置的更多细节以及对这些结果的进一步讨论（ğ6.1）。

我们还观察到使用基于事件驱动软件架构的另一种可编程缓存NGINX时，客户之间也存在类似的性能干扰{s}，表明这些问题在更广泛的可编程边缘环境中具有普遍性。此外，我们与领先的内容分发网络Fastly的工程师沟通后确认，性能干扰确实是他们在生产环境中观察到的问题[8]。例如，Fastly的工程师已观察到客户提供的VCL逻辑意外触发了Fastly分支版本Varnish中的病态性能情况，以及供应商提供的库中的缺陷导致同步原语的低效使用[8]。

为了探究性能干扰的来源，我们使用处理时间[36]来估计请求对系统资源的需求。请求在某个资源上的处理时间是指该资源在独立运行时完成服务所需的时间（以微秒为单位），除以该资源的并行处理能力。例如，一个请求在8核心CPU上的CPU处理时间，等于单个核心处理一个请求所需的时间除以8。一个请求的最大处理时间即为其瓶颈资源[36]。

我们估算了两种资源上的请求处理时间：CPU和客户端出口网卡（客户端全双工网卡的一个方向）。其他系统资源的处理时间可以忽略不计，因此予以省略。为了简化分析，我们假设多种资源不会同时处理同一个请求。对于CPU，我们计算IRC，其中I是处理请求时执行的指令数量（通过Linux性能监控API[72]测量），R是CPU时钟频率，C是系统总核心数。对于网卡，我们计算bT+hT⌈b最大传输单元−h⌉，其中b是传输的数据位数（由系统调用返回），h是TCP/IP头部的大小（以位为单位），T是网卡传输速率。我们假设最大传输单元为1500字节，TCP/IP头部为64字节TCP/IP头部。

表1显示了每个客户的请求处理时间。为了确保上述假设不会使我们的分析失效，我们确认了由表1预测的瓶颈资源与每个请求的真实瓶颈资源相匹配。我们发现，来自不同客户的请求具有不同的瓶颈资源。更重要的是，从图3和表1可以看出，性能干扰不仅发生在具有相同瓶颈资源的客户之间，也发生在具有不同瓶颈资源的客户之间。

启用Linux现有的（单资源）公平调度器来管理CPU和网卡，似乎有助于缓解性能干扰问题[41, 49]。尽管我们承认，在所有客户的瓶颈资源相同的情况下这是有效的，但这种按资源公平[36]存在两个缺点：第一，它不具备策略‐证明性[36]。这一点将在下一节中定义，但关键结论是，内容分发网络不应依赖客户行为良好才能实现公平性。第二，对于某些资源（例如内存带宽），由于当前硬件的并行特性，很难实现公平调度器。这限制了该方法向更多资源扩展的能力。

鉴于在具有不同瓶颈资源的客户之间观察到的性能干扰，我们认为，可编程边缘代理中的性能干扰问题最好通过多资源公平性（MRF）[37]的视角进行研究，并利用多资源公平队列（MRFQ）文献中的技术加以解决。

4 个关键挑战

4.1 前提条件

一个请求的主导资源是需要最多处理时间的资源。例如，表1显示了四个客户的主导资源分别是CPU、网络、网络和网络。多资源公平性(MRF)调度器确保在一组竞争的流中，每个流（即流向单个客户服务的请求流）在其各自的瓶颈资源上获得相等的处理时间。例如，客户C1可能获得CPU 30%的处理时间，而客户C2、客户C3和客户C4各自获得网卡30%的处理时间。

在N个流之间实施多资源公平性可提供三个重要属性[36, 37]：

(1) 份额保证：每个流将至少获得 1/N的系统资源；
(2) 防策略性操纵：任何流都无法通过操纵其工作负载（例如，更改其VCL）来获取超过其公平份额的系统资源；
(3) 工作守恒：当存在排队请求时，若有空闲的系统资源，并且使用这些资源能够提高某个流的吞吐量，则这些资源将始终被利用。

前两个特性使得多资源公平性(MRF)非常适用于缓解上一节中观察到的性能干扰。然而，正如我们将要展示的，尽管第三个特性在原始论文的理论模型中成立，但在实际中却无法成立，导致系统资源利用率不足。

多资源循环调度

循环调度器，如多资源循环调度（MR3）[68],实现出队操作，每个请求执行一次，具有O(1)的时间复杂度。其他MRFQ调度器的出队操作为 O(log |Qac|)，其中Qac是排队或活跃客户组成的集合。由于砂纸必须处理高达数十万请求的峰值负载，这些请求面向数千个客户的服务，因此我们采用MR3作为砂纸的基础。

类似于其他轮转调度器，对于每个客户，MR3维护一个先进先出输入队列和一个银行账户以跟踪资源使用情况[44, 61, 68]。客户流在一系列轮次中按固定顺序获得服务。新到达的客户被追加到该顺序的末尾。在每一轮中，一个量子u被存入每个客户的账户中。MR3释放某个客户的请求，直到该客户的账户余额不足以覆盖其队列头部请求的主导处理时间为止。然后MR3转向下一个客户。客户在每轮中最多可超额消耗1个请求，但其超额消耗将在下一轮中被扣除。与其他使用固定大小量子[61],的轮转调度器不同，MR3的量子大小u在每轮开始时被设置为上一轮中任何客户产生的最大超额消耗值。

4.2 应用级调度

在Varnish的应用程序运行时内部实施多资源公平性具有实际优势：首先，它在不同硬件之间具有可移植性。其次，它可以避免对运行在同一台机器上的其他应用程序施加额外负担。

Varnish。例如，Fastly在Varnish旁边部署了多个应用，如DNS解析器[22]。但在应用级部署调度器会带来挑战，因为新的调度器将运行在操作系统现有的资源调度器之上。

现有的MRFQ文献假设调度器能够完全控制系统的资源，并且资源在非抢占式先进先出规则下处理请求[36, 69, 70]。相比之下，应用级MRFQ调度器对操作系统的资源调度器以及资源的控制能力有限。例如，Linux的完全公平调度器（CFS）管理线程（即工作线程）的执行[49]。因此，应用级MRFQ调度器无法强制CPU开始处理某个请求；哪个工作线程实际获得CPU时间由CFS决定。此外，CFS近似于广义处理器共享（GPS），而非先进先出队列[49, 54]。它将CPU时间均等地分配给所有可运行线程，新变为可运行状态的线程会立即开始获得处理时间。这些差异使得应用级MRFQ调度器难以精确检测系统资源的过载情况，从而影响其实施公平性的能力。

图4展示了这一问题。我们在Varnish中实现了MR3[68]；实验设置与第3.2节和第6节中描述的相同。我们再次绘制了CPU和网络受限的客户在归一化吞吐量比率（越接近1表示公平性越高）上的对比，同时改变工作池的最大大小以及正在处理的最大并发请求数（即每个客户的闭环[60]客户端数量）。当工作线程少于40个时，两个客户的请求均未使其瓶颈资源达到饱和，因此我们省略了该范围。随着工作池中的工作线程数量接近请求数量，MR3在保证客户之间的公平性方面效果逐渐减弱。我们将在第5.2节中讨论解决此问题的关键洞察和方法。

4.3 并行资源

我们还发现，MR3（及类似变体）可能导致资源利用率低下，因为它限制了并发处理的请求数量[68, 70]。

图5使用我们系统的一个简化模型MR3提供了该问题的关键直观解释。我们有两个客户P和Q，以及两种资源：CPU和网卡。CPU拥有两个相同的核心。与真实系统不同，假设MR3完全控制系统的资源。P的请求需要2微秒的CPU处理和1微秒的网卡传输，而Q的请求分别需要1微秒和2微秒。请注意，由于存在两个核心，单个核心处理一个请求所需的时间是上述处理时间的两倍。

图5（底部）展示了MR3处理来自P和Q的各4个请求积压时，调度过程的前12微秒。在将第R轮中客户c的下一个请求释放以进行处理之前，MR3必须等待至少一个来自客户c在第R轮的请求开始在最终资源——链路[68]上接受服务。由于该机制的存在，尽管有待处理的请求，其中一个核心几乎完全处于空闲状态；这些空闲周期以对角线图案标示。当并行度较高（例如大型多核服务器）且客户数量较少时，这一问题尤为突出。对于内容分发网络而言，由少量客户导致系统过载的情况十分常见，例如在突发流量期间；而由于服务器部署成本直接影响其运营成本，因此保持高资源利用率至关重要。遗憾的是，若移除该机制（或其他调度器[36]中的类似阻塞机制），则会导致无界最坏情况不公平性（即相对公平性）

5 设计

5.1 系统概述

砂纸包含两个新组件：工作池大小管理器（取代Varnish现有的管理器）和请求释放器（取代先进先出请求队列）。这两个组件完全包含在Varnish应用程序运行时中，无需对底层操作系统进行修改。图7重点展示了Varnish请求处理架构的关键变更，图8展示了该算法的详细信息。

问题建模 。请求的客户由其Host头部定义。在处理发往客户c的服务的请求i（记为pic）时，Varnish会执行客户c的VCL并加载其网页。托管Varnish的服务器包含一组索引资源R={r1 ,. . . , rm}。当处理pic时，其执行由资源配置文件Sic={sic,1, . . . , sic,m}表征，该文件是一组索引化的处理时间。在计算资源配置文件时，我们不区分由客户的VCL显式触发的执行与Varnish的运行时中任何支持性执行。

假设资源配置文件并非先验已知。给定一组客户及其VCL配置，我们希望在客户之间实施多资源公平性(MRF)。

Worker Pool Size Manager 。该组件解决了ğ4.2中提出的问题。砂纸在资源利用率和多资源公平性之间的权衡上提供了更实用的选择。如图4所示，默认情况下Varnish使用近乎无限数量的工作线程，这会妨碍应用级MRFQ调度器实施MRF的能力。另一方面，使用过少的工作线程则可能导致无法充分饱和现代服务器中常见的大型多核CPU。因此，砂纸的新池大小管理器负责调节工作池中的工作线程数量。其目标是在不浪费服务器资源的前提下，尽可能保持活跃工作线程数量最小，以提供最佳的公平性保证。

请求释放器 。如ğ4.3所示，即使拥有充足的工作线程，现有的MRFQ调度器在处理具有并行和流水线资源的系统时仍可能导致系统利用率不足，因为它们限制了系统中并发请求的数量。因此，我们开发了Sandpaper的请求释放器，这是一种新的、实用的MR3 [68]变体，能够解决此问题，在确保客户之间公平性的同时，充分饱和大规模并行资源。请求到达系统时会被enqueue到请求释放器中。请求释放器负责对请求进行重新排序，并将其传递给空闲工作节点。工作线程完成任务后，会将请求的处理时间报告给请求释放器。

ProvableGuarantees 。最后，我们在努力提升现有MRFQ调度器实用性的同时，也希望保留其形式化保证。我们在ğ5.3和ğ5.2中重点介绍了部分关键的理论结果，但将证明的详细内容留至附录。Sandpaper的请求释放器的设计源于我们的一个关键观察：在一种更贴近现实的系统模型下，该模型包含多线程执行和阻塞式网络I/O等特性，我们仍然可以证明砂纸在放宽条件下仍能保证公平性（附录 A）。然而，我们的新分析结果表明，砂纸的最坏情况下的不公平性与工作池中活跃工作线程的数量成正比。因此，我们还提供了分析结果，证明我们的新池大小管理器不会导致无界的工作池大小，从而避免无界不公平性（附录B）。尽管砂纸的形式化保证远弱于其他调度器，但砂纸实现了更好的系统利用率和性能。此外，我们在评估中表明，实际中的公平性通常远优于最坏情况界限（ğ6.3）。

5.2 池大小管理器

图4表明，为了允许任何应用级MRFQ调度器实施公平性：（1）我们必须限制工作池的大小；并且（2）池中的工作线程数量必须小于系统中并发请求的数量。由于我们无法事先知道并发请求的数量，因此必须将工作池的大小设置得尽可能小，以提供最佳的公平性保证。然而，过小的工作池可能导致系统并行资源利用不足。实证发现，当工作线程与核心比例为10:1时，即使使用需求最低的VCL和1000字节的HTTP对象，Varnish也能使我们的机器CPU达到饱和。因此，砂纸简单地将工作池大小设为W = 10C，其中C是核心数量。

但是，如果工人数量少于最大并发请求数，则会带来潜在风险，因为工作线程可能在从源服务器获取高延迟内容时发生阻塞。如果过多的请求发生阻塞，Varnish可能会耗尽工作线程。此外，如第5.1节所述，Sandpaper需要阻塞式网络I/O以正式保证公平性。因此，在请求从源服务器获取内容之前，它会通知调度器，调度器将为池中生成一个新的工作线程。新的工作线程开始处理其他请求，当处理完成后，原始工作线程终止，使池恢复到原始大小。

因此，我们需要证明在此方案下工作池的增长是有限的，因为砂纸的公平性保证取决于W。假设请求到达是一个速率为 λ的泊松过程，且内容获取延迟相互独立并服从均值为 1/μ的指数分布，我们使用连续时间马尔可夫链推导出一个解析结果（见附录B），证明由于内容获取阻塞而产生的额外工作线程的期望数量是有界的。由于源服务器并行处理请求，我们推导出系统中额外工作线程的期望数量为 λpm/μ，其中pm是缓存未命中的概率。假设 λ= 200,000 请求/秒，1/μ = 0.1秒，且pm = 0.15[14]；则额外工作线程的期望数量为3000。

尽管不太可能发生，但所有这些工作线程可能会同时重新加入池中。然而，请记住，从请求释放器的角度来看，这些请求本应已经获得服务，因为它们之前已被释放；它们暂时离开系统只是让排在它们后面的请求能够提前获得服务。因此，为简化处理，当请求重新加入时，我们让Linux的CFS来平衡已正在执行的请求以及从内容获取返回的请求的执行。该方案不会影响系统在较长时间尺度上的公平性，并避免了任何潜在的饥饿问题。

5.3 请求释放器

如第4.3节所述，MR3[68]限制了释放到系统中的请求数量，可能导致并行资源的利用率不足。因此，我们将此机制称为端到端同步。

要证明MR3的公平性保证，需要端到端同步，该保证以相对公平性边界（RFB）的形式表示，即在任意时间间隔[36, 68, 70]内，任意两位客户在其各自主导资源上所获得的处理时间之差。形式化定义如下：

RFB= sup
t1, t2:i,j ∈B(t1, t2)
Ti(t1, t2) − Tj(t1, t2)

其中， B(t1,t2)是时间间隔[t1,t2)内的活跃客户集合，Ti(t1, t2)是客户i在同一时间间隔内接收到的主导处理时间总和。

移除端到端同步可以解决我们的利用率问题，但也使MR3的保障失效。我们的关键洞察是利用系统属性来弥合资源利用率与公平性之间看似根本性的矛盾。因此，我们部署了一种移除了端到端同步的MR3,变体，并在更贴近实际的系统模型中证明其理论保障。下文提供了直观解释和证明概要。

实际系统的四个特性在处理请求时提供了某种松散形式的同步：第一，只有当工作线程空闲时，才会释放队列中的请求。第二，工作池的大小限制了并发处理的请求数量。第三，工作线程在网络I/O上阻塞，因此在当前请求完成网卡传输之前，无法开始处理下一个请求。第四，操作系统的CPU调度策略为CFS。这些特性共同作用，限制了资源之间排队的请求数量，并约束了请求完成的顺序。

在包含这些属性的系统模型下，移除MR3的端到端同步不会导致无界不公平性。事实上，在请求数量相对于工作线程（W）数量较多的积压期间，我们证明了 RFB存在。

定理5.1 。考虑在积压期内任意给定的一对客户i和j。我们有

|Ti(t1, t2) − Tj(t1, t2)| ≤ 2WL+ 2L

其中L是所有资源和所有客户中的最大处理时间。

为简化分析，定理5.1的证明除了上述四个系统属性外，还做了额外的假设。由于篇幅限制，我们将详细内容推迟到附录A中。

6 实现 & 评估 ON

我们使用测试平台和模拟器来评估我们的方法。首先，我们证明砂纸能够实现客户之间的公平性（ğ6.1）并改善尾部延迟（ğ6.2）。接着，我们评估请求释放器及其设计选择（ğ6.3）。然后，我们分析砂纸的可扩展性和性能开销（ğ6.4）。最后，我们通过案例研究展示砂纸在真实场景中缓解性能干扰的效果（ğ6.5）。

实验设置 。我们的测试平台运行在威斯康星大学 CloudLab集群[33]上。我们最多使用6台机器：最多4台用于负载生成，1台用于Varnish[7],，1台用于Apache HTTP服务器 [12]。每台机器配备两个Intel E5‐2660 10核2.60 GHz CPU和 128 GB DDR4内存，超线程已关闭。它们使用双端口Intel X520 10Gb网卡。我们使用wrk[39]进行闭环[60]负载生成。除非另有说明，我们将Varnish限制为使用8个物理核心。

实现细节 。我们将砂纸实现为对Varnish 6.0（commit52e8fb1）的修改，共包含1026行C语言代码（含空白字符）。我们的实现利用了现有的哈希表实现[34]。我们使用SimPy[59],这一离散事件仿真框架，用2687行Python代码（包括空白行）构建了Varnish请求处理的模拟器。我们采用与ğ3.2中描述相同的方法，包括相同的性能计数器，以估算CPU和网卡上的请求处理时间。请求释放器使用指数加权移动平均值 α= 0.9来估计每个客户当前的请求处理时间。为了减少性能开销，我们对20%的请求的性能计数器进行采样。

6.1 公平性与吞吐量

我们在Varnish中实现砂纸（Sandpaper）后，重新运行了图3（ğ3.2）中所示的实验。首先，我们使用100个客户端线程测量每个客户在独立运行时的平均吞吐量。各客户的基准吞吐量差异显著：客户C1为19,568 请求/秒，客户C2为11,005 请求/秒，客户C3为10,668 请求/秒，客户C4为26,966 请求/秒。对于每一对客户c1和c2 ,，我们随后使用每个客户100个客户端（总共200个）来测量当这两个客户的请求竞争处理时间时各自的平均吞吐量，并计算每个客户的归一化吞吐量μc1,c2/μc1。

图9再次绘制了每对客户归一化吞吐量的最小/最大比值。几乎所有配对的比值都更接近1，表明使用砂纸的Varnish更公平地分配其处理时间和资源。我们怀疑那些仍明显小于1的情况是由于砂纸的宽松公平性边界以及处理时间估计的不准确性所致。然而即使在这些情况下，砂纸对尾部延迟仍有显著影响，这将在下一节中讨论。我们还验证了砂纸并非通过简单地减慢原本获得较多处理时间的客户来提高公平性。相反，砂纸使Varnish能够更好地在客户之间分配其处理时间。

6.2 延迟

即使在公平性未被完全保证的情况下，Sandpaper对尾部延迟仍有显著影响。例如，在图9中，当C1和C3竞争时，C1的第99百分位延迟从39.42 ms增加到101.85 ms，而C3的第99百分位延迟则大幅降低，从4.83 秒降至19.89 毫秒。事实上，在图9的所有组合中，对于C2与C1的竞争场景，Sandpaper将最大第99百分位延迟从5.77 秒降低至411.80 毫秒。

6.3 评估RequestReleaser

我们使用模拟器来分析移除MR3的端到端同步对观察到的公平性的影响。然后，我们将此方法的性能与另一种解决方案进行比较。

经验公平性边界 。我们模拟了一个类似于图5所示的系统。我们将CPU核心数设置为12，以分析在我们的实验工作负载下MR3导致利用率不足的情况。图5与我们的模拟器之间的主要区别在于，线程对网卡的I/O调用是阻塞的，更接近于我们的真实系统，而不是在网卡前放入队列。我们为模拟的CPU调度器实现了广义处理器共享[54],，该机制被Linux的CFS近似实现。线程被均匀分配到每个核心上，并共享相同的调度优先级。我们将经验边界定义为任意两个客户之间主导资源使用（即主导资源上的总处理时间）的最大观测差异。

由于RFB仅描述最坏情况下的不公平性，我们在图10中研究了Sandpaper的请求释放器的经验边界。在每次实验中，来自两个客户的需求到达调度器。对于每个客户，我们使用在Varnish中通过实验测得的处理时间，如表1所示。实线表示当我们改变工作池中的工人数量（线程）W时，两名客户之间的经验边界。对于每一对模拟客户，我们增加W的值，直到聚合吞吐量不再上升为止。虚线曲线表示相应客户对的推导出的RFB（更多细节见附录A）。与RFB类似，经验边界也随着W的增加而呈现上升趋势。然而，经验边界明显小于推导出的RFB。我们注意到，悲观的相对公平性边界仅用于证明Sandpaper的请求释放器不会导致无界不公平性；该边界的紧致性并非我们的主要关注点。

替代方法 。通过移除端到端同步，我们得到了 MR3的一个变体，该变体被用于砂纸系统中。在本节中，我们将此变体称为移除同步（RS）。尽管RS存在相对公平性边界，但仍然难以理解或建模其他性能指标，例如RS的平均相对公平性或总吞吐量。因此，我们采用实证评估，并将其与另一种MR3的变体进行比较，后者引入了虚拟流（VF）以提高资源利用率。具体而言，VF将来自活跃客户i的请求拆分为一组 α个虚拟客户i(1)、i(2)、…、i(α)。对于一组Qac个活跃客户，VF人为地将虚拟流的总数膨胀至 α |Qac |。随后，VF在每个 α个虚拟组之间实施客户公平性（例如，i(2)和j(2)的进展受相同的RFB约束）。利用这种方法，我们可以直接沿用MR3相对公平性边界[68]的证明，从而证明VF也存在相对公平性边界。

我们比较了RS和VF在总吞吐量（即单位时间内所有客户处理的请求数量）方面的表现，作为经验边界函数。图11显示了两组代表性客户的结果。我们增加W和 α，直到总吞吐量不再增加为止。RS的数据点对应于 W小于核心数量的配置。关键观察结果是，当它们的经验不公平边界相等时，RS实现的吞吐量高于VF。其次，如预期所示，将W设置为核心数量以下的值会导致总吞吐量较低，因为工作线程无法使系统的模拟并行资源达到饱和。我们在其他客户对中也观察到了类似的模式。

根据这一分析，我们得出结论：与VF相比，当流达到相同的实证主导资源公平性水平时，RS能够实现更高的总吞吐量。此外，RS相较于VF具有实际优势。只要将W初始化为足够高的值，RS就不会导致CPU利用率不足，而砂纸的工作池大小管理器可保证这一点。该选择与活跃客户的数量无关。然而对于VF，当 α过小且活跃客户数量下降时，系统可能一直处于利用率不足的状态。因此，我们认为RS是砂纸更优且更简单的解决方案。

6.4 可扩展性与开销

我们研究了Sandpaper的可扩展性，并量化了其性能开销。

可扩展性 。为了展示砂纸使用真实客户VCL的可扩展性表现，我们比较了引入砂纸前后Varnish的最大吞吐量（每秒请求数）。我们通过增加客户数量来比较 Varnish的总吞吐量。对于给定的客户数N，我们使用 10N个连接生成负载。每个客户最多有10个请求由 Varnish并发处理。我们以客户C1作为代表客户，但发现其他客户的结果类似。

砂纸可轻松扩展到大量客户。其开销，即与未修改的Varnish相比在相同工作负载下的吞吐量百分比下降，当仅有少量客户时约为5%，在2000个客户提供 20,000个并发请求时最高达到8.6%。

开销 。为了量化砂纸的开销，我们使用默认（空操作）VCL和1KB HTML对象，在8核上以100个连接测量Varnish的吞吐量。此类请求需要的处理非常少，因此会放大砂纸引入的任何开销的影响。我们发现 Linux的perf事件子系统[72]是砂纸中最大的开销来源，其他研究也证实了我们在此处得到的数据[71]。仅启用每个线程的性能计数器，并在每个请求时读取它们以估计每个请求的处理时间，就会使该轻量级客户的吞吐量从248,767降至195,190 请求/秒，减少了20%。该开销包括两个部分：每次上下文切换带来的固定额外CPU处理量，以及一个可变组件——与计数器读取次数成正比的锁开销。我们通过采样20%的请求来减少后一部分，将此客户的开销降低至17%。其他研究表明剩余开销可以被消除[30, 71],，但我们将其技术集成到砂纸中的工作留待未来完成。

由于实验中使用的客户非常轻量，17%的开销代表了最坏情况。此外，随着客户增加其VCL的复杂度或 HTML对象的大小，剩余开销不会发生变化。对于图9 中显示的客户对，使用砂纸后的总吞吐量范围从 10,693 请求/秒（客户C3 vs. 客户C3）到27,078 请求/秒（客户C4 vs. 客户C4），而原始值为10,691 请求/秒到27,047 请求/秒。事实上，砂纸在所有真实客户工作负载上的开销均低于9%。

6.5 案例研究

我们展示了多个案例研究，以说明砂纸在真实场景中缓解了性能隔离问题。

客户内容变更 。当其他客户进行内容更改时，砂纸可保护客户的性能变化。在此实验中，我们测量了两个合成客户（静态和动态）在60秒内的平均吞吐量。对于每个客户，我们使用一个闭环[60]请求生成器[39]，配备100个客户端线程。最初，静态客户和动态客户的请求执行相同的 VCL并加载相同的网页。此时CPU原本是两者的瓶颈资源。然而，在20秒后，动态客户上传了一个更大的网页，使其瓶颈资源变为网络。最后，在额外的20秒后，动态客户撤销了该更改。

在图12中，我们看到在添加砂纸之前（虚线），Varnish无法缓解动态客户的性能干扰。由于它们的配置相同，每个客户的吞吐量最初相等，符合预期。在时间20时，由于动态客户的请求现在需要传输更多字节，我们预计其吞吐量会下降。然而理想情况下，静态客户并未更改其VCL或内容，应至少获得他们在动态客户变更之前的吞吐量；不幸的是，两个客户的吞吐量都急剧下降。

使用砂纸（实线）后，静态客户的吞吐量与动态客户的变化相互隔离。更理想的是，当动态客户发生变更时，其吞吐量反而上升，因为动态客户的瓶颈资源已转移到网卡，从而为静态客户的请求在CPU上留出了更多的处理时间。20秒之前和40秒之后吞吐量的差异是由于砂纸的性能开销，如前一节所述。

突发流量 。砂纸还能减轻突发流量造成的影响。我们采用了与上述类似的实验设置，但改变了动态客户的行为。在图13中，动态客户经历了三次

连接数激增时，动态客户的需求增加，而静态客户的需求则保持不变。第一次激增发生在时间10，持续1秒，并使动态客户的流量翻倍。通过比较虚线曲线（主干Varnish）和实线曲线（砂纸），我们注意到该激增对砂纸的影响可以忽略不计。第二次激增发生在时间20，持续5秒，流量再次翻倍。此时，主干Varnish的吞吐量受到更显著的影响，砂纸也表现出可察觉的影响。在时间40，第三次激增开始，持续时间与第二次相同，但幅度提升至3倍。对于砂纸而言，其影响与第二次激增几乎相同。因此，在突发流量情况下，砂纸下的客户性能相比主干Varnish更具弹性。

7 限制

我们强调本方法的一些关键局限性：首先，并非所有瓶颈都是由共享资源争用引起的，例如，不同客户的吞吐量可能受限于源服务器的可用带宽。然而，砂纸主要关注的是在本地服务器资源上实施公平性；外部瓶颈不在当前方法的范围之内。在此类情况下应用砂纸不会导致不公平的结果，但可能无法实现竞争客户所期望的吞吐量均等降低。其次，砂纸的部分方法和假设可能不适用于采用事件驱动软件架构的系统[13, 15]。但我们认为，这些方法适用于其他使用基于线程的架构的CDN边缘环境[7, 11, 16]。此外，我们已证明性能干扰问题在这些其他架构中普遍存在（ğ3.2），并认为砂纸中的设计思路可为事件驱动架构中的潜在解决方案提供基础（例如，在请求释放到事件处理器之前进行排队）。最后，Sandpaper的请求释放器需要一种准确估算请求处理时间的方法。对于我们的原型，我们采用指数加权移动平均值，但这可能并非在所有情况下都适用。由于最佳的估算方法因应用而异，我们认为开发更优的估算器超出了我们的研究范围。

8 结论

我们提出了砂纸（Sandpaper），一种新的多资源公平队列调度器，用于在CDN边缘平台中实现客户之间的性能隔离。砂纸在设计上解决了实际部署中的挑战；其完全实现在用户空间中，无需对底层操作系统进行修改。与现有调度器相比，砂纸在多资源公平性与资源利用率之间提供了更实用的权衡。砂纸的设计得益于对理论系统模型与实际系统之间差异的关键洞察，使我们能够在提供理论保障的同时提升现有调度器的性能。我们证明了砂纸在基于真实客户工作负载的真实场景中，在缓解性能干扰方面表现良好。