基于WebAssembly的Delta Sync云存储服务

ACM Transactions on Storage，Vol.号183、第二十四条。出版日期：2022年9月→基于WebAssembly的Delta Sync云存储服务郑建伟，李振华，邱远辉，林浩，何晓，杨丽，刘云浩，清华大学增量同步（sync）对于云存储服务的网络级效率至关重要，特别是在以小增量处理大文件然而，实际的增量同步技术仅适用于PC客户端和移动应用程序，而不适用于Web浏览器-这是最普遍且与操作系统无关的访问方法。为了弥合这一差距，先前的工作集中在反转增量同步协议或利用本机客户端上，所有这些都围绕效率、适用性和可用性之间的权衡而努力，从而形成“不可能的三角形”。最近，我们注意到WebAssembly（WASM）的出现，这是一种可移植的二进制指令格式，在编码大小和加载时间方面都很有效原则上，WASM的独特优势可以使基于Web的应用程序享受接近原生的运行时速度，而无需显着的云端或客户端更改。因此，我们实现了一个简单的基于WASM的增量同步解决方案，WASMrsync，发现它的准异步工作方式和传统的原位分离内存分配大大增加了同步时间和内存使用。为了解决这些问题，我们战略性地设计了同步代码解耦和流式编译，以及知情的就地文件构造。由此产生的解决方案WASMrsync+实现了与最先进（最高效）的解决方案相当的同步时间，几乎只有一半的内存使用，让“不可能的三角形”达到和解。CCS概念：·信息系统信息存储系统;存储架构;基于云的存储;其他关键词和短语：云存储服务，增量同步，Web浏览器，WebAssemblyACM参考格式：Jianwei Zheng，Zhenhua Li，Yuanhui Qiu，Hao Lin，He Xiao，Yang Li，and Yunhao Liu.2022年基于WebAssembly的Delta Sync云存储服务。 ACM Trans. 存储18，3，第24条（2022年9月），31页。https://doi.org/10.1145/35028471介绍近年来，Dropbox、Google Drive、iCloud Drive和Microsoft OneDrive等云存储服务大受欢迎它们不仅为数十亿互联网用户提供了方便和普及的数据存储，而且还成为其他在线应用程序的关键组成部分它们的流行给客户端和云端带来了大量的网络流量开销[18，38]。因此，在提高其网络水平方面做了大量的努力这项工作得到了中国国家自然科学基金委员会（NSFC）的部分支持，基金编号为61822205，61902211和62202266，以及微软亚洲研究作 者 Zheng ， Z.Li （ 通 讯 作 者 ） ， Y.Qiu ， H.Lin ， H. 肖 氏 Y.Li 和 Y.Liu， 清 华 大 学 ， 北 京 ; 电 子 邮 件 ：zhengjw19@mails.tsinghua.edu.cn，lizhenhua1983@gmail.comqiuyh0924@163.com，linhaomails@www.example.comgmail.comxiaoh16@gmail.comliyang14thu@gmail.com，和unhaoliu@gmail.com。允许制作本作品的全部或部分数字或硬拷贝供个人或课堂使用，无需付费，前提是复制品不以营利或商业利益为目的制作或分发，并且复制品在第一页上带有此通知和完整的引用版权的组成部分，这项工作所拥有的其他人比ACM必须尊重。允许用信用进行提取 复制，或重新发布，张贴在服务器上或重新分发到列表，需要事先特定的许可和/或费用。从permissions@acm.org请求权限。© 2022计算机协会1553-3077/2022/09-ART24 $15.00https://doi.org/10.1145/350284724ACM Transactions on Storage，Vol.号183、第二十四条。出版日期：2022年9月二十四：2J. Zheng等人∼∼效率，如批量同步，延迟同步，增量同步，压缩和重复数据删除[12，13，17，38，39，57]。在这些努力中，增量同步由于其细粒度（即，客户端仅将文件的更改内容而不是整个文件发送到云），从而在存在用户的文件编辑的情况下实现显著的流量节省[19，40，41]。不幸的是，今天的增量同步仅适用于最先进的商业云存储服务中的PC客户端和/或移动应用程序（如第2节所述），但不适用于Web-最普遍和独立于操作系统的访问方法。以Dropbox为例，当用户将文件f编辑成新版本f j后，Dropbox的PC客户端会应用delta sync，仅自动将修改后的比特上传到云端;相比之1这个差距在同步速度和流量成本方面显著影响了基于Web的用户体验[19，46，47]。Web是云存储服务的流行访问方法[20，30，32]：所有主要服务都支持基于Web的访问，同时仅为有限的操作系统分布和设备集提供PC客户端和移动应用程序原因之一是许多用户不想在他们的设备上安装PC客户端或移动应用程序，以避免额外的存储和CPU/内存开销;相比之下，几乎每个设备都有Web浏览器。特别地，对于新兴的面向云的系统和设备（例如，Chrome OS和Chromebook）网络浏览器可能是访问云存储的唯一选择为了了解基于Web的增量同步的根本障碍，我们使用最先进的Web技术（包括JavaScript、WebSocket和HTML5 File API [31，45]）实现了增量同步解决方案WebRsync，以实现快速文件I/O和传输。WebRsync实现了rsync的算法[49]，并适用于所有现代Web浏览器。实验结果表明，WebRsync的同步速度远低于基于PC客户端的同步，因为WebRsync受到严重影响Web浏览器中的JavaScript执行效率很低因此，我们优化WebRsync的第一种方法是利用本机客户端[25]，这是一个在Web浏览器中高效安全地执行编译后的C/C++代码的沙箱我们通过开发WebRsync-native实现了这一方法，实验表明，它可以实现与基于PC客户端的rsync相当的同步时间。然而，使用本机客户端需要客户端侧下载并安装用于web浏览器的插件，这实质上损害了WebRsync-native的可用性和普及性。在上述观察的推动下，我们对基于Web的高效增量同步的第二个努力是最终的解决方案被命名为WebR2sync（基于Web的反向rsync）。它大大减少了Web客户端的计算负担，但给服务器端带来了相当大的计算开销。 为此，我们做了额外的双重努力来优化服务器端的计算开销。首先，我们利用用户文件编辑的局部性其次，通过利用轻量级校验和算法SipHash [9]和Spooky [11] 而不 是 MD5 ， 我 们 可 以 将 块比较的 复 杂 性 降 低 5 倍 。 该 解 决 方 案 被 称 为WebR2sync+。然而，WebR2sync+由于反向方案而打破了rsync的原始工作流程因此，主流云存储系统需要重构其架构以采用WebR2sync+，这极大地限制了WebR2sync+的工业适用性此外，SipHash的冲突概率远远高于MD5。因此，WebR2sync+存在比其他解决方案产生更多同步错误的风险，这极大地削弱了WebR2sync+的系统可靠性。1在本文中，我们将重点介绍将文件同步到云存储的任何应用程序所进行的普遍文件编辑通过Web浏览器，而不是特定的基于Web的文件编辑器，如Google Reader，Microsoft Word Online，Overleaf和GitHub在线编辑器。从技术上讲，我们的测量表明，后者通常利用特定的数据结构（而不是增量同步）来避免完整内容传输并节省文件编辑所产生的网络流量。基于WebAssembly的Delta Sync云存储服务二十四：3ACM Transactions on Storage，Vol.号183、第二十四条。出版日期：2022年9月∼∼上述解决方案，包括WebRsync、WebRsync-native和WebR 2sync+，似乎都在努力在效率、适用性和可用性之间进行权衡，如表1中比较列出的。尽管如此，我们仍然希望探索构建一个高效的基于Web的增量同步解决方案的可能性，而不牺牲适用性或可用性。最近，一种名为WebAssembly[54]（或简称WASM）的新兴技术（或Web语言）在Web应用程序设计中引起了越来越多的关注 WASM是一种可移植的二进制指令格式（用于Web编程语言），在编码大小和加载时间方面都很有效。WASM的独特优势似乎可以使基于Web的增量同步应用程序享受接近本机的运行时速度，而无需对云端或客户端进行重大更改。因此，我们探索如何利用WASM以用户友好且易于应用的方式（即，使这两个世界最好的观察到MD5校验和的计算在客户端产生最大的计算开销，我们利用WASM来执行此操作，从而产生称为WASMrsync的初步为了避免阻塞可能导致网页无响应的主线程，WASMAPI被设计为异步的。因此，我们必须使用准异步策略来实现WASMrsync使用JavaScript的await/await c机制以同步方式不幸的是，运行await/await/await c方法会产生一些开销：必须捕获当前执行上下文，有一个线程转换，并构建一个状态机，代码通过该状态机运行。更糟糕的是，WASMAPI调用的await/await c属性会传播到调用的包装函数，这会为执行包装函数中的非WASM代码带来不必要的开销，从而严重增加了整体同步时间。 为了减轻这个缺点，我们战略性地设计了sync-WASM 代 码 解 耦 ， 从异步模块中提 取 同 步 的 非 WASM 代 码 ， 以 避 免 不 必 要 的await/WASM开销。此外，为了提高异步WASM模块的加载效率，我们采用了流-ingcompilation（一种新颖的WASM API），用于并行下载和编译WASM模块。使用WASM时，浏览器通常需要依次下载、编译和实例化WASM模块，然后通过JavaScript调用从该模块导出的函数通过流式编译，浏览器可以在下载模块字节的同时开始编译WASM模块。一旦浏览器下载了单个函数的所有字节，该函数就可以传递给后台线程进行编译，这从本质上提高了加载效率。此外，当处理大文件时，我们注意到WASMrsync遭受在服务器端的耗时和内存消耗的文件构造操作，这源于传统的原位分离内存分配（ISMA）机制。因此，我们设计了信息就地文件构造（IIFC）机制，通过（1）用依赖图将动作编码到更新文件的每个块（ADD或COPY），（2）对图进行拓扑排序，以及（3）将处理后的信息从客户端传递到服务器端。因此，我们只需要根据旧文件占用的内存空间执行一次增量内存分配。最 终 的 解 决 方 案 名 为 WASMrsync+ 。 我 们 评 估 WebRsync- native ， WebR 2sync+ 和WASMrsync+的性能，通过构建基于Dropbox的系统架构的原型系统结果表明，WebRsync-native可以显著减少WebRsync的同步时间-事实上，接近rsync的同步时间-同时牺牲可用性。WebR2sync+比WebRsync快了一个数量级，也接近rsync的性能，但代价是适用性有限相比之下，WASMrsync+实现了与WebR 2sync+相当的同步时间（前者仅比后者多花10%-20%的同步时间），并节省了50%的服务器端内存使用，但不会影响可靠性，适用性和可用性。二十四：4J. Zheng等人ACM Transactions on Storage，Vol.号183、第二十四条。出版日期：2022年9月安装表1.本文中提出和实现的基于Web和WASM的增量同步解决方案的简要比较，从技术、停滞（Web浏览器）效率、适用性和可用性系统技术停滞效率适用性可用性HTML文件API和WebSocket是低顺利通过容易WebRsync- 本地原生客户端否高平滑采用额外插件WebRsync- 平行HTML5web workers没有低顺利通过容易编辑局部性利用和轻量级哈希是中等顺利采用容易使用以下命令反转rsyncWebR2sync服务器端优化系统架构重构系统架构重构容易容易WASMrsync WebAssembly否中等顺利采用容易具有客户端和服务器端优化的WASMrsyncNo High顺利通过Easy总之，我们的工作做出了以下贡献：我们详细阐述了深入和全面研究基于Web和WASM的增量同步解决方案的方法，涉及量化其性能的关键指标和工作负载，以及准确量化Web浏览器停滞的自动化工具（第3节）。我们以逐步优化的方式提出了各种基于Web的增量同步解决方案，以揭示在传统框架中支持增量同步的挑战和机遇（第4节）。我们通过开发第一个可行的基于WASM的增量同步解决方案（WASMrsync）（第5节），探索利用WASM以用户友好和易于应用的方式实现高效的基于Web的增量同步的实际可行性。我们通过设计客户端和服务器端优化来实现一个高效的基于WASM的增量同步解决方案（WASMrsync+），而不会牺牲适用性或可用性（第6节）。最后，我们在表1中比较了本文中提出和实现的所有基于Web和WASM的增量同步解决方案，以便读者可以轻松地了解它们之间的差异。 我们还在www.example.com上公开了所有源代码https://WASMDeltaSync.github.io。2相关工作和现状增量同步，称为增量编码或增量压缩，是一种以文件的不同版本之间的差异（增量）的形式存储或传输数据的方式，而不是文件的完整内容[56]。它对于文件修改或增量数据更新频繁发生的网络应用程序非常有用，例如，存储文件的多个版本，将连续的用户编辑分发到文件，以及传输视频序列[28]。 在过去的四十年中，已经提出了各种各样的增量同步算法或解决方案，例如UNIX diff [27]，Vcdiff [33]，WebExpress [26]，乐观增量[10]，rsync [49]和内容定义的块。美国疾病控制与预防中心（CDC）[34]。WebRsyncWebRsync+WebR2syncWebR2sync+没有高不存在中度WASMrsync+····基于WebAssembly的Delta Sync云存储服务二十四：5ACM Transactions on Storage，Vol.号183、第二十四条。出版日期：2022年9月由于其高效性和灵活性，rsync已成为实际上广泛使用 它最初是由Tridgell和Mackerras在1996年提出的，作为一种通过高延迟、低带宽网络链路进行有效远程数据更新的算法[52]。然后，在1999年，Tridgell在参考文献[51]中彻底讨论了它的设计，实现和性能作为所有流行的Linux发行版中包含的标准Linux实用程序， rsync也被移植到Windows，FreeBSD，NetBSD，OpenBSD和MacOS [49]。根据真实世界的使用数据集[38]，大多数（84%）文件至少被用户修改过一次，从而证实了增量同步对云存储服务的网络级效率的重要性在所有主流云存储服务中，Dropbox是第一个在2009年左右在其基于PC客户端的文件同步过程中采用delta sync（更具体地说，rsync）的服务。然后，SugarSync、iCloud Drive、OneDrive和Seafile遵循Dropbox的设计选择，利用增量同步（rsync或CDC）来减少PC客户端 之后，两个学术云存储系统，即QuickSync [13]和DeltaCFS [64]，进一步为移动应用程序实现了增量同步（分别为rsync和CDC）。Drago等人研究了Dropbox的系统架构，并基于Dropbox网络流量的ISP级跟踪进行了大规模测量[18]。他们观察到Dropbox的流量高达YouTube流量的三分之一，这加强了Dropbox采用delta sync的必要性Li等人通过各种类型的受控基准测试实验详细研究了Dropbox的增量同步过程，发现在频繁、短数据更新的情况下，它存在流量和计算过度使用问题[40]。 为此，他们设计了一种高效的批量同步算法，称为UDS（update-batched delayed sync），以减少流量使用，并通过向后兼容的Linux内核修改进一步扩展了UDS，以减少CPU使用（回想一下增量同步是计算密集型的）。尽管增量同步（特别是rsync）在云存储服务中被广泛采用，但实际的增量同步技术目前仅适用于PC客户端和移动应用程序，而不是Web浏览器。我们对最先进的云存储服务中的增量同步支持进行了定性研究目标服务的选择是根据其受欢迎程度（Dropbox，Google Drive ，Microsoft OneDrive ， iCloud Drive 和 Box.com ） 或 所 使 用 技 术 的 代 表 性 （ SugarSync ，Seafile，QuickSync和DeltaCFS）。对于每项服务，我们使用其最新版本（截至2021年3月）的Windows PC客户端、Android应用程序和Chrome Web浏览器，检查了其对不同访问方法的增量同步支持唯一的例外发生在iCloud Drive上，我们使用其最新版本的MacOS客户端，iOS应用程序和Safari Web浏览器。为了检查具有特定访问方法的特定服务，我们首先上传了一个1MB2的高将新文件（f）压缩到云（因此产生的网络流量将略大于1 MB）。接下来，在用户端，我们向f追加一个字节，以生成更新后的文件FJ。之后，我们用特定的访问方法将用户的FJ同步到云端，同时记录网络流量消耗。通过这种方式，我们可以通过测量流量消耗来揭示是否应用了增量同步-如果流量消耗大于1 MB，则服务不采用增量同步;否则（即， 流量消耗仅为几十KB），该服务已实现增量同步。根据表2中列出的检查结果，我们有以下观察结果：第一，增量同步已被广泛采用在大多数云存储服务的PC客户端 然而，它从来没有被任何流行的云存储服务的移动应用程序使用过，尽管两个学术服务[13，64]已经在他们的移动应用程序中实现了增量同步并证明了其有效性。事实上，随着移动应用程序的电池容量和能源效率不断增长，我们预计Delta Sync将在不久的将来被移动应用程序广泛采用[37]。最后，2我们还对大小远大于1 MB的文件进行了实验，即，10 MB和100 MB，得到了相同的结果。二十四：6J. Zheng等人ACM Transactions on Storage，Vol.号183、第二十四条。出版日期：2022年9月表2.九种云存储服务中的Delta Sync支持服务PC客户端手机AppWeb浏览器Dropbox是的没有没有Google Drive没有没有没有OneDrive是的没有没有iCloud Drive是的没有没有Box.com没有没有没有SugarSync是的没有没有免费WiFi [50]是的没有没有[13]第十三话是的是的没有DeltaCFS [64]是的是的没有所研究的云存储服务支持基于web的增量同步，尽管web浏览器构成了用于访问因特网服务的最普遍和与操作系统无关的方法为此，我们首先介绍了基于Web的增量同步的一般思想，包括基本动机、初步设计和使用有限工作负载和指标的早期性能评估[61]。然而，在实践中，我们注意到，单独利用传统的web可靠性、适用性和可用性）。幸运的是，WebAssembly的出现[54]揭示了如何以有效和实用的方式启用基于Web的应用程序。已经提出了许多有用的基于WebAssembly的浏览器应用程序，例如交互式3D可视化[21]，资源会计[24]，音频和视频软件[36]和游戏[63]。为此，我们进一步介绍了基于WebAssembly的增量同步，并使用有限的工作负载和指标进行了初步设计、实现、优化和性能评估。在这篇文章中，我们的工作是在参考文献[62]的基础上进行的，同时在技术，评估和演示方面超越了它3研究方法在本节中，为了全面了解在当前Web框架下支持增量同步的挑战和机遇，我们设计了各种定量实验来对基于Web的增量同步系统进行基准测试。我们首先提出了几个指标来评估基于Web的增量同步系统的性能（第3.1节），然后提出了各种工作负载来评估这些指标（第3.2节）。我们还开发了一个名为StagMeter的工具来测量这些系统的客户端停滞（第3.4节）。最后，我们设置了一个类似Dropbox的架构（作为最先进的工业云存储服务的一个示例），其中包含第3.3节中详细介绍的服务器、客户端和网络配置。除了一个新的度量（内存使用）和一个新的工作负载（重工作负载）之外，我们在以前的工作中提出了该方法的其他部分[38，62]。3.1度量我们提出了五个指标来衡量我们的实验结果：（1）同步效率，它测量文件操作同步到云的速度;（2）计算开销，它解释了基于Web的增量同步系统的同步效率的差异;（3）同步流量，它量化了每个基于Web的增量同步系统消耗的网络流量;（4）内存使用，它揭示了基于Web的增量同步系统的服务器端所需的内存空间量;以及（5）服务吞吐量，它显示了使用标准VM服务器实例的每个基于Web的增量同步系统的可扩展性。基于WebAssembly的Delta Sync云存储服务二十四：7ACM Transactions on Storage，Vol.号183、第二十四条。出版日期：2022年9月≥∼≥∼∼3.2工作负载为了评估每个基于web的增量同步系统在各种实际使用场景下的性能，我们生成简单的（即，单次），常规（即，周期性的）、密集的，和重的（即，大文件）工作负载。 为了生成简单的工作负载，我们对从真实世界的云存储服务收集的真实世界的文件进行随机的附加、插入和剪切3个不同编辑大小（范围从1 B、10 B、100 B、1 KB、10 KB到100 KB）的操作。该数据集是在我们以前的工作中收集的，并公开发布[38]，其中平均文件大小接近1 MB。一个文件只被编辑一次（所谓的“一次性”），然后从客户端同步到服务器端。对于插入或剪切操作，当其编辑大小为1 KB时，它首先被分散为1-20个连续的子编辑4，然后像简单的工作负载一样定期和密集的工作负载主要用于评估每个系统的服务吞吐量。为了生成常规的工作负载，我们仍然对一个典型的文件进行某种类型的编辑，其文件大小为5 MB，但编辑操作每10秒执行一次为了生成实际密集型工作负载，我们使用了一个基准测试，其中包含来自Linux内核源代码树的两个连续版本（版本4.5和4.6）的超过8，755对源文件源文件的平均大小为23KB，文件编辑局部性通常比图15中的更强（如图1所示）。具体来说，我们首先将旧版本的所有文件以类似FTP的方式上传到服务器然后，我们使用目标方法将新版本的所有文件逐个同步到服务器端两次连续文件同步之间没有时间间隔繁重的工作量是用来调查基于Web的增量同步系统在大文件编辑场景中的性能为了创建繁重的工作负载，我们生成不同大小的大型文件（范围从10 MB、20 MB、40 MB、60 MB、80 MB到100 MB），以模拟真实世界的文件。然后，我们还对这些大文件进行不同编辑大小（从1 B，10 B，100 B，1 KB，10 KB，100 KB到1 MB）的随机追加，插入和剪切操作。我们只对每个文件进行一次编辑，并将它们从客户端同步到服务器端。对于插入或剪切，当其编辑大小为1 KB时，也首先将其分散为1-就像简单的工作负载一样。3.3实验装置使用上述测量指标和工作负载，我们进行了各种基于Web的增量同步系统的比较测量研究。 对于每个系统，我们通过在从阿里云ECS租用的标准VM服务器实例（具有四核Intel Xeon CPU@2. 5GHz和16 GB内存）上运行Web服务来设置类似Dropbox的系统架构，并且所有文件内容都托管在从阿里云OSS租用的对象存储上。 ECS VM服务器和OSS存储位于同一数据中心，因此它们之间没有瓶颈。每个系统的客户端在Google Chrome浏览器（Windows版本56.0）中执行，该浏览器运行在具有四核Intel Core-i5 CPU@2.8 GHz、16 GB内存和SSD磁盘的笔记本电脑上。服务器侧和客户端侧位于不同的城市（即，上海和北京）和不同的ISP（即，中国联通和CERNET），如图2所示。网络RTT为30 ms，网络带宽为100 Mbps.因此，在我们的实验中，网络瓶颈保持最小，因此主要的系统瓶颈位于服务器和/或客户端。 如果网络状况变得更糟，那么主要的系统瓶颈可能会转移到网络连接上。3在这里，4连续子编辑意味着子编辑操作发生在文件中的连续字节上。更多细节在第4.3.2节中解释，特别是在图14和图15中。二十四：8J. Zheng等人ACM Transactions on Storage，Vol.号183、第二十四条。出版日期：2022年9月图1. 两个连续的Linux内核版本（版本4.5和4.6）的源文件中的文件编辑位置。3.4测量停滞图2. 在中国的实验设置在实践中，计算密集型操作（例如，块搜索和比较）通常在基于web的增量同步系统的客户端侧带来相当大的计算开销大量的CPU消耗导致Web浏览器经常停滞甚至挂起。为了定量地了解用户感知到的Web浏览器的停滞，我们开发了StagMeter工具，通过将一段JavaScript代码自动集成到Web浏览器中来测量停滞时间5StagMeter周期性地6在相关网页上打印当前时间戳（例如，执行增量同步的网页如果当前时间戳（比如，t）此时被成功打印，则不存在停滞;否则，存在停滞，则当前时间戳的打印将被推迟到tJ>t。因此，相应的停滞时间计算为t J− t。4基于Web的DELTA SYNC值得一提的是，本节介绍了我们以前工作的贡献[62]。在本节中，我们将以逐步优化的方式介绍各种基于Web的增量同步解决方案首先，我们提出了第一个可行的解决方案，名为WebRsync，作为4.1节中的基线。通过性能基准测试，我们发现了We-bRsync存在的不足. 然后，我们研究了几个客户端优化，以部分解决WebRsync的缺点。测量结果表明，WebRsync的缺点无法通过客户端优化从根本上解决因此，我们在第4.3节中介绍了WebR2sync+，这是基于Web的增量同步的初步实用解决方案。 尽管它们不是满足高同步效率和实用性两者的实际上可接受的解决方案（即，可应用性、可用性和可靠性），它们指出了在当前web框架下支持增量同步的挑战和优化机会。4.1WebRsyncWebRsync是云存储服务中第一个可行的基于Web的增量同步实现它基于HTML5 File API [45]和WebSocket在JavaScript中实现它遵循rsync算法，因此与基于PC客户端的方法保持相同的行为4.1.1设计和实施。我们设计WebRsync，rsync到web浏览器场景。如图3所示，在WebRsync中，当用户编辑5我们还可以直接使用Chrome浏览器的本地分析工具来可视化停滞，其结果我们比StagMeter更难解释6默认情况下，我们将周期设置为100 ms，以模拟普通Web用户操作的最小间隔基于WebAssembly的Delta Sync云存储服务二十四：9ACM Transactions on Storage，Vol.号183、第二十四条。出版日期：2022年9月图3. WebRsync的设计流程图文件从f到fJ，客户端立即向服务器发送文件同步的请求在接收到请求时，服务器首先对f（在云侧可用）执行固定大小的块分割和指纹识别操作，然后向客户端返回f的校验和列表除了最后一个区块，每个数据区块的大小通常为8 KB因此，当f的大小为1 MB时，其校验和列表包含128个弱32位校验和以及128个强128位MD5校验和[49]。之后，基于f的校验和列表，客户端首先对fj执行块搜索和比较操作，然后生成匹配的令牌和文字字节。请注意，搜索和比较操作都是以逐字节的方式对滚动校验和进行的;相比之下，分段和指纹识别操作都是以逐块的方式进行的，因此它们的计算开销要低得多。匹配的标记表示f和f J之间的重叠，而文字字节表示f J中相对于f的新颖部分。它们都被发送到服务器用于构造FJ。最后，服务器向客户端返回确认以结束该过程。我们基于HTML5 File API [45]和Web-Socket协议实现了WebRsync的客户端，使用了1,500行JavaScript代码。 遵循优化JavaScript执行性能的常见做法，我们采用asm.js语言[8]首先用C代码编写WebRsync的客户端，然后将其编译为JavaScript。WebRsync的服务器端是基于node.js框架开发的，有500行node.js代码和600行C代码;其架构遵循Dropbox的服务器架构。与Dropbox类似，WebRsync的Web服务运行在从阿里云ECS租用的VM服务器上[5]，文件内容托管在从阿里云OSS租用的对象存储上[6]。有关服务器、客户端和网络配置的更多细节，请参见第3.3节和图2。4.1.2性能基准。 我们首先比较WebRsync和rsync在简单工作负载下的性能，以揭示启用基于Web的增量同步的挑战和优化机会。我们对真实世界的文件执行不同编辑大小（范围从1 B，10 B，100 B，1 KB，10 KB到100 KB）的随机追加，插入和剪切操作[38]，如第3.2节所述。对于三种不同类型的编辑操作中的每一种，我们首先测量其对应于每个编辑大小的平均同步时间，然后将平均同步时间分解为三个阶段：服务器，网络和客户端。此外，我们还测量了每个编辑大小对应的客户端平均CPU利用率。如图4所示，对于每种类型的文件编辑操作，WebRsync的同步时间明显长于rsync（16换句话说，在处理相同的文件编辑时，WebRsync比rsync慢得多。 在三种类型的文件编辑中，我们注意到使用WebRsync同步剪切操作总是比同步追加/插入操作快（对于相同的编辑大小），特别是当编辑大小相对较大（10 KB或100 KB）时。这是因为二十四：J. Zheng等人ACM Transactions on Storage，Vol.号183、第二十四条。出版日期：2022年9月图第四章在简单的工作负载下，使用WebRsync进行各种大小的文件编辑（包括追加、插入和剪切）的平均同步时间。误差条显示每个点的最小值和最大值图5. （a）rsync和（b）WebRsync用于追加操作的同步时间的细分，以及相应的平均客户端CPU利用率。插入和切割操作的情况类似。剪切操作减少文件的长度，而附加/插入操作增加文件的长度。此外，我们将rsync和WebRsync的同步时间分解为三个阶段：在客户端，通过网络，以及在服务器端，如图5（a）和5（b）所示。 对于每种类型的文件编辑，rsync的同步时间大约有40%花在客户端，大约35%花在网络端;相比之下，WebRsync的同步时间绝大多数（60%-92%）花在客户端，而不到5%花在网络端。这表明WebRsync的同步瓶颈是由于Web浏览器执行JavaScript代码的效率低下此外，图5（c）说明了WebRsync中每种类型的文件编辑的CPU利用率几乎是rsync的两倍，因为JavaScript程序消耗更多的CPU资源。大量的CPU消耗导致Web浏览器经常停滞甚至挂起。使用第3.4节StagMeter中提到的测量工具，我们测量并可视化了WebRsync的停滞（在处理三种类型的文件编辑时），如图6所示。请注意，StagMeter仅尝试在第一秒打印10个时间戳因此，连续时间戳之间的间隔表示停滞，并且更大的间隔意味着更长的停滞。 如所有三个子图所示，停滞与高CPU利用率直接相关。4.2WebRsync的本地扩展、并行化和客户端优化我们研究了三种方法来部分解决WebRsync的缺点。对于每种方法，我们首先描述其工作原理，然后使用不同类型的文件编辑来评估其性能。WebRsync-native。 考虑到WebRsync的同步速度远低于基于PC客户端的增量同步解决方案（rsync），我们优化WebRsync的第一种方法是利用基于WebAssembly的Delta Sync云存储服务二十四：ACM Transactions on Storage，Vol.号183、第二十四条。出版日期：2022年9月图第六章StagMeter为不同的编辑操作和相关的CPU利用率捕获的停滞停滞时间由同步处理时间上的时间戳的中断来说明图第七章在简单的工作负载下，使用WebRsync-native进行各种大小的文件编辑的平均同步时间Web浏览器的本地客户端[25]本机客户端是一个沙箱，用于在Web浏览器中有效和安全地执行编译的C/C++代码，并已被所有主流Web浏览器支持。在我们的实现中，我们使用Chrome本地客户端来加速Chrome浏览器上WebRsync的执行我们首先使用HTML5和JavaScript来组成网页界面，通过该界面，用户可以选择要同步（到云）的本地文件然后，所选本地文件的路径被发送到我们开发的本地客户端（用C++编写）。然后，本机客户端读取文件内容，并以与rsync类似的方式将其复制到云。 当同步过程完成时，本机客户端向网页界面返回确认消息，然后向用户显示增量同步操作的成功。图7描述了WebRsync-native与原始WebRsync的性能对比。显然，WebRsync-native显著减少了WebRsync的同步时间，实际上接近rsync的同步时间。因此，CPU利用率降低，完全避免了Chrome浏览器的停滞。然而，使用本机客户端需要用户为Web浏览器下载和安装额外的插件组件，这本质上损害了WebRsync-native的可用性和普及性。WebRsync-parallel. 我们的第二种方法是使用HTML5 Web Workers [15]来实现并行或线程。一般来说，当在网页中执行JavaScript代码时，网页在执行完成之前没有响应-这就是为什么WebRsync会导致Web浏览器频繁停滞甚至挂起。 为了解决这个问题，Web worker是一个在后台运行的JavaScript程序，独立于同一网页中的其他JavaScript程序。当我们将其应用于WebRsync时，原始的单个JavaScript程序被划分为并行工作的多个JavaScript程序虽然这种方法几乎不能减少总同步时间（如图8所示）或CPU利用率（如图9所示，二十四：J. Zheng等人ACM Transactions on Storage，Vol.号183、第二十四条。出版日期：2022年9月图第八章在简单的工作负载下，使用WebRsync-parallel进行各种大小的文件编辑的平均同步时间图第九章 虽然WebRsync-parallel无法降低CPU利用率（相对于WebRsync），但它可以通过利用HTML5Web Workers来完全避免Chrome Web浏览器的停滞。上半部分），完全可以避免Chrome浏览器的停滞（如图9下半部分所示）。WebRsync+. 稍后，在4.3节中，我们将详细描述如何利用用户的文件编辑局部性和轻量级哈希算法来减少服务器端的计算开销。事实上，双重优化也可以应用于客户端。因此，我们在WebRsync的客户端实现了这两种优化机制，将它们从C++翻译成JavaScript，并将得到的解决方案称为WebRsync+ 。 如 图 10 所 示 ， 由 于 客 户 端 优 化 ， WebRsync+ 在 同 步 时 间 方 面 明 显 超 过WebRsync，这基本上在我们的预期之内。此外，我们将WebRsync+的同步时间分解为三个阶段：客户端、网络和服务器端，如图11所示。比较图11和图5（b）（WebRsync的同步时间分为三个阶段），我们发现WebRsync+的客户端时间成本显著降低，这要归功于两种优化机制。然而，WebRsync+不能完全避免Web