Caching Doesn’t Improve Mobile Web Performance (Much)

原版地址，点我

说明：

本文为博主自己翻译，水平有限，仅供参考。

1. 画删除线部分我也不知道咋翻译。
2. 加粗部分为论文重点表达。
3. 红色部分为扩展链接
4. 浅蓝色部分为博主个人理解

概述：

      最近的NSDI论文报道，将HTTP proxy的缓存命中率从22％提高到32％，使移动客户端的中间页面加载时间（PLT）提高了不到2％。 我们认为这种弱改进有两个主要原因：关键路径上的对象通常不被缓存，并且移动设备的有限计算能力导致计算延迟这是由于关键路径由很大一部分组成。
      事实上，这两个因素都是先前对桌面网络性能的分析所概述的[2]。 但是，我们（作为HTTP-proxy的作者）没有正确理解分析，如果有的话，本可以节省大量的工程费用。 因此，我们认为有必要强调这一先前的分析，并将分析扩展到包括具有慢CPU，精确缓存命中率和HTTP proxy缓存结果的受控再现的移动设备。 在完美缓存命中率的极端情况下，与没有缓存相比，桌面页面加载时间显着提高了34％，但移动页面加载时间仅在平均情况下提高了13％。 我们从这些结果中提取性能模型，以帮助理解其根本原因。

一. 介绍：

      Web缓存广泛应用于减少网络连接的使用，减少服务器负载和数据使用、提高可靠性为终端的Web服务器，并改善与终端主机的延迟。 这里，我们专注于影响web缓存的潜在因素，通过以网页加载时间来度量。
      Google的HTTP proxy Flywheel 将其整体缓存命中率从22％提高到32％，但在平均情况下，页面加载时间仅减少了1-2％。 作为Flywheel的设计师，我们最初对这种微弱的改进感到惊讶。 如果我们能够预测缓存会产生如此微不足道的影响，那么我们本可以节省大量的工程成本。

Flywheel: Google's Data Compression Proxy for the Mobile Webhttps://ai.google/research/pubs/pub43447
      测量网页加载关键路径的部分放在了论文的第5和第6部分。Wang等人为他们的测量工具寻求证明的用例。他们中的两个使用了这样的方式：一个分析CPU速度的变化，一个分析网页加载Cache的冷温热。 事实上，这都是为了概述flywheel结果的根本可能。

冷：表示没有缓存； 温：部分缓存；热：完美缓存
      在本文中，我们试图强调Wang等人的分析。我们怀疑我们并不是唯一一个持有误解的人：缓存应该可以改善延迟。 我们也沿着几个方向扩展他们的分析。 我们提出了一种方法用于以细粒度改变缓存命中率，并进行测量缓存对网页的影响通过在移动设备和桌面浏览器上以一个可控和可重现的方式。在我们受控制的环境中，我们重现了飞轮的报告在 Alexa网站上的400个网页的缓存命中率增加而发现PLT(页面加载时间)相对于平均减少了1％。 在完美缓存命中率的极端情况下，我们发现桌面页面加载时间相比没有缓存明显减少了34％，但是移动端页面加载时间仅仅平均减少了13％。
      我们开发了这个 back-of-the-envelope 表现模型并且填充了其中的参数以使得更加方便观察来更好的理解这种现象造成的原因。我们的模型表明，CPU速度是阻止移动设备从Web缓存中获益的关键资源瓶颈。 Wang等人分析，似乎进一步表明关键路径上的对象通常不会被缓存（甚至不可缓存）。
      我们的分析表明，一般情况下，良好的桌面延迟改进并不能很好地适应移动客户端。 内容提供商可能需要三思而后行，将缓存资源用作改善延迟的手段，尤其是当移动流量开始超过桌面流量时。

二. 背景 和 模型

      浏览器和移动应用程序通常都使用HTTP（S）协议加载内容。 当用户将浏览器（或应用程序）定向到新URL时，浏览器的Object Loader将获取根HTML对象，如图1所示.HTML Parser为HTML中的每个链接资源启动其他获取请求。 通过这种方式，浏览器逐步生成DOM。 在页面加载时，Rendering组件绘制UI。
      从用户的角度来看，可以根据许多不同的度量来定义网站的性能。 在这里，我们专注于页面加载时间，它可以很容易地在浏览器中进行测量和标准化。

      网页加载时间：粗略地说，页面加载时间（PLT）是从用户请求网页的那一刻到页面上所有的资源被加载所经过的时间。 我们通过监听浏览器的JavaScript onload事件来测量PLT，当所有资源都添加到DOM时，大多数浏览器都会触发该事件，并且所有图像，脚本，链接和frames都已完成加载。
      关键路径： 网页由许多对象组成，例如图像，JavaScript，CSS和HTML。 这些对象中的每一个都由多个（可能是并发的）浏览器任务处理：必须对其进行提取，解析，分析和渲染。我们将非重叠的解析和渲染对象的延迟称为“计算延迟”，将获取内容延迟称为“网络延迟”。
      关键路径分析是一种分析并行进程（如浏览器）性能的方法。 某些加载任务依赖于其他任务，必须等到其前任任务完成。 网页的关键路径是最长的依赖浏览器任务链，因此减少不在关键路径上的任何任务的长度不会改变页面加载时间。 在图2中，HTML，CSS，JS和JPEG对象的网络和计算延迟决定了PLT。 如果我们要减少加载PNG对象的延迟，关键路径将保持不变，因此PLT不会改变。这句话点名主题

2.1 Performance Model(性能模型)

我们现在可以了解缓存对其(PLT)的影响通过一个简单的性能模型。 首先，看一下以下声明：

• 设X表示给定的缓存命中率,我们将缓存命中率定义为由缓存提供服务的网页中所有对象的分数。 请注意，X的最大值是页面上可缓存内容的分数，可能小于1。
• 设K表示关键路径上可缓存对象部分的分数。
• 设N表示关键路径上所有对象的网络提取延迟的总和，用于冷（X = 0）页面加载。
• 设C表示冷（X = 0）页面加载的关键路径上所有对象的计算延迟的总和。
• 设f（X）表示关键路径上的计算延迟和网络延迟之间的重叠，通常，关键路径上的依赖对象不应重叠。但是，在某些情况下，浏览器可以在其前面仅获取部分内容加载时同时开始加载对象。 在大多数情况下，我们可以忽略f（X）。
        为简单起见，让我们假设（i）关键路径不会随着我们改变缓存命中率而改变，（ii）对象在缓存中的概率在所有可缓存对象中是均匀的，以及（iii）缓存项目的网络延迟为零。 然后，关键路径上的对象产生网络延迟的概率：
  
  因此，给定X的PLT的预期值是：
  

2.2拟合模型

      WProf论文的第5和第6节包含关键路径的经验测量，使我们能够在上面的模型中粗略地理解N，C和K的值。
      拟合N和C. 在图3中，我们为torchbrowser.com重现了WProf的“whatif”分析（来自WProf的图13)。 该实验研究了不同网络和计算速度对性能的影响我们首先将网页中所有对象的计算或网络延迟乘以固定常数。 然后，我们重新计算页面的关键路径（基于WProf捕获的任务依赖性），并提取预测的PLT。 comp = 1行表示加载原始页面的（2 GHz）桌面CPU，而comp = 0表示无限快的CPU，comp = 1/2表示CPU速度快两倍，comp = 2（不存在） 在WProf的分析中）表示CPU速度的一半。

      对于无限快速的CPU（comp = 0），我们看到它的网络速度不变（网络时间比= 1）的标准化PLT应该是~0.8。 当我们改善这个CPU的网络延迟时，我们应该看到理论上无限加速（趋向于PLT为0）。 相反，对于最慢的CPU（comp = 2），无限快速网络的标准化PLT（网络时间= 0的比率）是〜0.4。实验结果证明了 CPU速度对PLT的影响，而不是网络延迟。对于这个假设的CPU（假设f（·）接近于0），我们可以估计由计算延迟组成的关键路径的分数是〜0.4，而由网络延迟组成的关键路径的分数是〜0.6。这一分析的关键在于，随着我们降低CPU的速度，C：N的比率继续增加。 例如，我们的分析表明，对于类似于torchbrowser.com的网站，具有~1 GHz CPU [9]的典型移动设备的C：N比率为~2 / 3。 这具有直观意义：与较快的CPU相比，较慢的CPU会导致计算延迟构成关键路径的较大部分。
      拟合K.为了在WProf中生成图11b，作者在使用冷缓存加载页面后立即测量了缓存中对象的比例。 尽管65％的对象都被缓存，但关键路径上的所有对象中只有20％被缓存，从而给出了K = 0.2的估计值。
      启示。 WProf的分析以及我们的模型让我们粗略地了解了缓存的性能影响。 我们回到§4中的模型，在那里我们寻求更深入的经验理解。

三. 实验仪器

      为了更深入地理解§2.1和§2.2中概述的性能动态，我们需要通过实验评估缓存如何在受控环境中影响PLT。 在这里，我们用来我们自己的方法。
      我们的实验设备（可在[10]公开获得）利用遥测[11]和网页重放（WPR）[12]来测量参数化网络延迟水平的影响。 遥测和WPR都是Chromium [13]的一部分，Chromium是Google Chrome的开源组件。 在这里，我们将“浏览器”一词与谷歌浏览器互换使用。
      网页重播。 WPR充当本地DNS和HTTP（S）代理缓存（如图4a所示）。 在记录模式下，WPR将HTTP（S）请求转发到Internet，并记录它观察到的所有请求和响应，以及观察到的网络延迟等元数据。由此，Web Page Replay构建了一个WPR存档（如图4b所示），包含所有HTTP（S）请求，响应，标头，数据和网络延迟。
      在重放模式下，WPR代理使用存档中保存的响应来响应HTTP（S）请求，如果相应的响应未保存在存档中，则响应404错误响应。 我们将WPR配置为仅在睡眠之后发送匹配的响应和数据，该持续时间最初被观察为源和WPR代理之间的网络延迟（当它处于记录模式时）。 在这里，WPR模拟边缘缓存而不是浏览器缓存。
      遥测：遥测（图4c）是一个浏览器性能测试框架，它编排浏览器和WPR的行为。 我们使用遥测来控制两个浏览器中的一个。 第一个是在虚拟机中运行的桌面版Google Chrome（3.2中的规范）。 第二种是在USB连接的移动设备上运行的移动版Google Chrome。 我们使用遥测技术在浏览器中加载请求的URL（就像用户在多功能框中输入URL一样）并被动地测量PLT。

3.1工作流程

在每次实验之前，我们清除浏览器缓存确保试验的一致性。 对于每个设备（桌面和
移动），我们为每个URL执行以下步骤：

• 首先，我们使用遥测技术从Internet记录实时网页，以指示浏览器获取给定的URL。 WPR代理接收此HTTP（S）请求，将其转发到Internet，并被动地检查和记录双向流量，如§3中所述。 我们将此数据存储为WPR存档。
• 接下来，我们确定具有冷缓存的网页的页面加载时间。 在WPR处于重放模式时，我们将URL加载四次（参见§3.3）并将最小页面加载时间作为我们的PLT值，以考虑方差。
• 现在，我们模拟一个“完美的”，完全填充的缓存。 首先，我们将原始WPR存档复制到新的WPR存档中。对于这个新的WPR存档中的每个可缓存响应，我们将其网络延迟设置为0（当然，“实际”缓存响应时间为0是不可能的，但我们将其设置为绝对下限）。 HTTP标头指示的不可缓存项目会保留其初始网络延迟。 我们将这个经过修改的档案与原始档案一起存储（图4b）。
• 最后，我们再次记录页面加载时间，但这次使用修改后的WPR存档。 我们以与原始相同的方式确定PLT。 然后，我们将未修改的重放执行的页面加载时间与修改后的“完美缓存”执行的页面加载时间进行比较。
        部分缓存方法：为了确认Flywheel的发现，我们创建了另外两组部分缓存的WPR档案：一个缓存随机选择的30％的可缓存资源（无论字节大小), 和另一个缓存20％。 我们确保20％WPR存档中的缓存项目是30％WPR存档中缓存项目的严格子集，以确保一致性。

3.2规格

      每个网页最初都是通过加州大学伯克利分校的局域网获取的，其速度接近250 Mbps，最高速度为230 Mbps。 我们的移动设备是Galaxy Tab 4，配备1.2 GHz四核处理器和运行Android 4.4 KitKat的1.5 GB板载内存。 桌面结果在具有3.2 GHz四核处理器和6 GB RAM的虚拟机中执行。

3.3已知限制

      我们确定了我们设备的以下限制，并且讨论我们选择工具背后的原因：
      页面加载时间作为度量标准:在确定网页性能时，我们选择关注页面加载时间而不是SpeedIndex [5]或高于时间[4]。 虽然它们可以说是更好的指标（因为它们可以更好地捕获用户的观点），但这些指标是
更难衡量。
      WPR测量精度：WPR采取的PLT测量不一定与实时网页上观察到的PLT一致，也不一定在多次WPR运行中保持一致。 首先，虽然WPR试图减轻JavaScript执行中的非确定性（通过在插入非确定性调用（例如getTime）的每个网页中注入脚本），但JavaScript仍然可能在不同的负载上表现出非确定性。 其次，WPR用于模拟在记录模式期间观察到的原始RTT（睡眠固定的毫秒数）的机制可能与原始页面加载的行为不完全匹配。 我们尝试通过将每个网页加载四次并采用最小PLT.1来缓解这些工件

四. 结果

在这里，我们展示了我们在仪器中发现的经验性能结果。 我们还试图强调决定我们结果的潜在影响。

4.1工作量特征

我们首先注意到数据语料库的几个关键特征：

• 数据集。 我们选择了400的随机子集 Alexa排名前2000的URL [3]并加载了他们的根URL（’/’）。
• 可缓存字节的分数。 我们工作负载中超过90％的网页将超过90％的总字节标记为可缓存，如图5a所示。
• 总字节数。 图5b显示了我们数据集中网页大小的扩展。 虽然95％的网页不到6.8 MB，但网页中位数小于1.2 MB。
• 初始网络延迟。 在所有请求/响应对中，发送请求和接收第一个响应字节之间的中间延迟为50ms，平均值为151.17ms，标准差为403.77ms。

      用户代理。 现在，许多网页都针对移动设备进行了优化。 Web服务器检查传入HTTP（S）请求的用户代理（UA），以根据其设备大小和计算资源向客户端提供定制内容。 我们运行了两次所有实验：一次是浏览器（桌面和移动设备）宣传移动UA，一次是浏览器宣传桌面UA。 我们发现结果的差异是可比的。 在这里，我们仅显示桌面UA结果，以使我们的图表更具可读性。

4.2绩效结果

      正如我们在图5a中看到的，90％的页面由> 90％的可缓存字节组成。 如果网络延迟占主导地位且关键路径上的可缓存对象的比例适中，那么可以得出结论，PLT在完美缓存中可以忽略不计。 然而，正如我们的模型预测的那样，这不是观察到的结果。
      缓存不会显着减少移动PLT。 我们通过模拟20％和30％的缓存命中率，在我们的受控环境中重现了飞轮的结果。 如图5c所示，我们发现将命中率提高10个百分点对移动页面加载时间的影响可以忽略不计。 与报告的飞轮结果一致，我们观察到中位数情况下PLT仅减少1％。 凭借完美的缓存（图6），我们的移动设备在中位数情况下仅减少了13％的PLT，而其桌面版本则降低了34％的PLT。
有限的RAM不会影响计算延迟。 有限的RAM或有限的CPU可能并不会增加关键路径上的计算延迟。 在这里，我们试图孤立哪些资源发挥更大的作用。
      目前全球市场上的典型移动设备有1 GHz处理器和1 GB RAM [9]。 我们模拟这些条件并将计算资源与受不同资源约束的虚拟机隔离（使用VirtualBox设置内存使用限制或模拟较慢的CPU时钟速度）。 以“移动”和“无限制”“桌面”作为基线，图6显示了这些资源限制之间的鲜明对比：我们的CPU约束VM（“约束 - 1 GHz CPU”）与我们的平板电脑（“移动”）的行为非常相似， 而我们的RAM约束VM（‘Constrained - 1 GB RAM’）与’Desktop’结果更紧密地对齐。 由此我们得出结论，CPU（而不是RAM）在确定缓存的性能改进方面发挥着更大的作用
      CPU速度慢会增加计算延迟。 现在我们已将CPU作为瓶颈资源孤立起来，我们试图衡量其影响程度。 就我们的模型而言，我们已经知道较慢的CPU应该产生更高的计算延迟，但是在这里我们试图理解经验观察到的C：N的比率（与图3中的假设的预测比率相反）。在图7中，我们观察到，正如我们预测的那样，当我们限制CPU约束时，完美缓存对PLT的影响明显较小。
      缓存的边际效益急剧下降。 图8显示，对于缓存命中率每增加10个百分点，移动页面加载时间仅减少1个百分点。 也就是说，缓存的每个附加字节的边际性能增益都会急剧下降。 这个实验证据支持我们的模型：虽然我们不直接测量关键路径（因为WProf目前不适用于移动浏览器），但似乎关键路径（K）上可缓存字节的比例明显小于 可缓存的byes不在关键路径上。

4.3数据验证

      我们做了一些努力来理智地检查我们的结果[14]。 为了减轻非确定性，我们比较了浏览器中加载的所有对象的状态代码，包括原始和完美/部分缓存基准。 我们过滤了400个URL数据集中大约9％的网页，如果由于WPR存档中没有响应的非确定性请求而存在大量404错误代码。 我们提供的数据仅显示通过我们的非确定性过滤器的这些网页的91％。
      随着网页中缓存与非缓存字节的比例增加，我们希望页面加载时间小于或等于其非缓存对应的时间。 如图8所示，缓存字节的比例与PLT的减少之间存在正相关，尽管是渐近的。 但是，由于PLT的差异（在§3.3中讨论），我们在图6中看到，当缓存时，~10％的网页表现更差，如X = 0左侧的数据点所示。

5相关工作

      现在已经有好几篇论文分析了网络性能，缓存和CPU速度和PLT之间的关系。
      WProf。 王等人。 [2]是对我们最近的研究。 正如我们在§2中讨论的那样，WProf为其图11运行的实验表明，关键路径上的对象通常不会被缓存; 他们为图13运行的实验意味着降低CPU速度会导致计算延迟占关键路径的较大部分。
      我们从几个方面扩展他们的研究。 我们开发了一个模型，允许我们预测给定缓存命中率的PLT。 我们表明有限的RAM不会增加计算延迟，尽管CPU速度很慢。 我们还通过更大的数据集（400个URL，相对于~50个URL），经验性地测量（而非静态计算，如WProf所做的）使用平板设备的PLT，以及使用CPU约束的虚拟机。 最后，我们扩展了WProf的可缓存性分析，以显示缓存的边际收益急剧减少。
      在我们的工作的同时，Nejati等人。 将WProf移植到移动浏览器[15]。 虽然他们不考虑缓存，但他们的工具对于深化我们的分析是非常宝贵的。
      网络表现。 相关研究[16,17]侧重于评估和优化桌面的Web性能。 已经利用诸如改变内容，数据压缩，代理服务和CDN的许多技术来减少用户的等待时间。 这些研究专注于高性能终端设备，如台式机。 我们还在移动设备上分析和比较了网络性能。
      王振等。 [18,19]已经确定桌面网页加载中最大的延迟因素是浏览器中的对象呈现。 他们进一步表明CPU限制是资源加载缓慢的主要原因。 对于大型数据集，我们强调他们声称CPU约束是确定页面加载时间的关键因素。 我们还证明，由于移动设备的CPU速度有限，Web缓存的优势正在减少。
      我们不是第一个专注于移动设备的网络性能的人[18,19]。 我们的主要贡献是开发一种性能模型，用于指出桌面和移动设备之间的主要差异。
      网络缓存。 其他文献[20-23]专注于网络缓存的好处，特别是减少桌面的延迟[24-28]。 虽然这些论文记录了缓存的几个好处，但它们并没有专注于突出缓存对（CPU受限）移动设备的影响。
      建议对Web进行更改。 有许多论文[29-37]建议对网络进行更改，以便通过更好的缓存方案改善网络延迟。 根据他们提出的更改，缓存可能会为移动延迟带来更多好处。 在本文中，我们只关注当今现有的基础架构。

六. 结论

      由于我们最初对Flywheel在智能缓存方面的性能改善表示惊讶，我们试图突出并扩展Wang等人所做的分析。 两个原因表明缓存对提供移动端的页面加载时间没有太大的意义：CPU速度慢，以及关键路径上缓存项目的稀疏性。 为了有效地使用缓存，内容提供者应该特别注意缓存的对象是否在关键路径上。
关键路径上做缓存应该是指分析、渲染等。。
      展望未来，移动设备正变得越来越强大，瓶颈资源也将发生变化。 我们希望我们在这里开发的模型能够帮助内容提供商和网络设计人员对未来移动网络缓存的性能影响做出明智的决策。
      致谢。 我们感谢匿名审稿人他们的反馈，特别是我们的牧羊人Dan Tsafrir 帮助我们发展我们的绩效模型。 这项研究得到了NSF研究生研究奖学金的支持。