Marauder-高效缓存和预取加速手机APP
本次解读的文章来自MobiSys‘21,研究如何高效加速移动应用程序响应,研究人员来自UCLA、密歇根大学以及普林斯顿大学。
背景&问题
移动应用程序已成为移动用户访问互联网服务的主要媒介,占智能手机用户关注时间的80%以上,手机应用成功的关键是较低的响应时间和用户感知的延迟。Android官方给出的报告显示用户对仅仅100毫秒量级的延迟反应消极,如果响应时间超过2-3秒,他们会放弃交互甚至删除应用。 鉴于移动应用程序性能的重要性,许多工作都致力于提高它们的响应能力。很多研究认为网络传输延迟是导致高响应时间的主要原因,本文也基于此。目前,有两种主要的技术来减轻网络延迟对应用响应的负面影响:缓存和预取。原则上,两都非常有效,特别是考虑到用户在与应用程序交互时表现出的重复模式。然而,每一种都有基本的缺点,这些缺点限制了它们在实践中的使用和有效性。
动机
实验设置
-
实验负载:论文收集75个各种类别的Android App,关注其中的50个(使用流行的OkHttp缓存库);
-
用户交互模拟:论文使用了人形应用测试框架Humanoid app测试框架,它采用深度神经网络从实际用户轨迹中学习交互模式;
-
运行设置:对每个应用程序考虑默认的APK,以及嵌入Marauder的变体两种情况,在Google Pixel 4和Samsung Galaxy Note 9上运行;随机选择每个应用程序的5个用户交互轨迹,并以𝛿分钟为间隔进行应用。根据之前对用户-应用程序交互的研究,论文考虑10分钟到1天的𝛿值;如果未说明,默认值为𝛿 = 60𝑚𝑖𝑛𝑠。实验过程网络环境包括家庭WiFi和LTE网络;
-
性能基准:本文主要的性能指标是用户响应时间IRT(interaction response time),即用户执行屏幕点击以触发交互的时间与交互的最终屏幕完全呈现的时间之间的时间。(具体测量方法详见论文介绍);
相关结论
- 现在的手机APP交互太慢:
图 3显示应用程序和跟踪的交互响应时间 (IRT) 分布,IRT 值的中位数和第 90 个百分位数在 WiFi 网络上分别为 1.6 和 3.7 秒,在 LTE 网络上跃升至 2.9 和 6.7 秒。因此,交互响应时间经常超过用户愿意容忍的 2-3 秒。
- 网络延迟是关键因素:
移动应用程序的响应时间取决于内容获取过程中产生的网络延迟,以及在APK中解析/呈现该内容和其他代码的客户端计算延迟。对于每个交互,论文比较了有和没有网络延迟的IRT。如图4所示,网络延迟分别占WiFi和LTE中值交互IRT的38%和64%。
- 现有优化存在局限:
上述实验中,应用程序采用默认运行模式,应用程序的APK或源服务器指定的任何缓存或预取都会被采用。然而,响应时间仍然过长。
缓存的问题:现有的缓存要求开发人员为他们服务的每个资源显式设置一个TTL。然而,设置这样的TTL是困难的,因为每个资源的理想TTL随时间而变化。论文的实验中,50%资源的理想TTLs的标准偏差是2小时,在这种情况下,开发人员面临着权衡;
预取的问题:应用程序对预取的支持通常选择获取大量内容的通用策略,其中大部分内容没有被使用。因此,尽管有潜在的加速,实际上预取在资源使用方面是非常浪费的。这种浪费会导致较高的通信成本,并且还会影响IRT加速,尤其是在带宽受限的设置中,其中明确请求的资源必须与不必要预取的资源竞争;
设计
Marauder是一个移动应用程序加速框架,其目标是同时利用缓存和预取的能力,尽量回避它们的风险和局限性。Marauder的关键思想是使用明智的预取来最大化已经缓存的对象的效用(即缓存命中),然后使用这些缓存的对象来指导即时预取(即在当前交互期间)。
观察
观察一:论文发现为给定交互提取的文本文件(即 JSON、HTML、JavaScript、CSS 和 XML)直接嵌入了该交互所需的大多数非文本资源的列表,94%提取的非文本资源的URL可以从以前提取的文本文件中获得。所以,当应用程序解析和执行文本文件时,可以直接从应用程序的缓存中发出对任何引用文件的预取请求。这样,文本文件的早期解析和执行延迟会与被引用的非文本文件的网络获取延迟重叠。而且,这种JIT(just-in-time)的预取的风险会很低因为它只考虑直接列在文件中的资源,该文件被显式地请求并且将要被解析;
观察二:论文观察到缓存资源的内容通常保持不变,尽管相应的 TTL 已过期(这发生在47% 的资源中),这表明现有缓存TTL 设置过于保守。所以可以通过预取即将到期的资源,在它们没有改变的情况下延长它们的TTL(从而提高它们的命中率);
观察三:论文发现给定文本文件引用的文件集通常在很长一段时间内保持稳定,即使文本内容发生变化也是如此。例如,中间文本文件的引用文件集在4小时内保持不变,尽管50%的文本文件仅在20分钟内保持不变。将此条件放宽到只有90%的引用文件未更改,将中位持续时间增加到9小时。所以可以通过在验证/更新不可缓存的文本文件并随后解析该文本文件时,对该文本文件所引用的文件发出预取请求,减少条件检查所带来的延迟。。
后台操作
-
Cache Refresher:刷新缓存资源,以提高整体缓存命中率。对于缓存中具有非零TTL的每个资源(即,不包括标记为非缓存的资源),Marauder添加一个计时器事件,该事件在到期时检查资源的内容是否没有改变,以及其TTL是否可以延长。按照上面的观察二,Marauder对文本和非文本文件执行不同的TTL扩展过程;
-
JIT Prefetcher:促进文本文件引用的资源的在线预取。每当一个文本文件被添加到应用程序缓存时(即使它被标记为无缓存), Marauder 都会异步生成一个工作线程来解析相应文本文件的正文以搜索引用的URL。开发人员使用各种正则表达式和 LinkedIn URL 检测器库静态分析文本文件,以查找所有类似于 URL 的字符串;
运行流程
在用户交互期间,应用程序发出的请求正常访问缓存存在三种潜在的情况,每种情况都需要使用 Marauder 的不同工作流程。
-
对于第一次请求文本文件(即,它不在缓存中,甚至过期),或者任何请求非文本文件但在应用程序缓存中未命中的请求,Marauder会立即通过网络发出请求。收到响应后,Marauder将内容发送到应用程序,将其添加到缓存中,如果它是文本文件,则开始后台任务以提取引用的资源;
-
对于在应用程序缓存中命中的文本文件请求(根据缓存库的默认命中标准),Marauder用相应的内容响应应用程序,并立即对该文本文件引用的所有文件发出异步预取请求(使用离线生成的列表)。预取请求首先通过应用程序缓存,确保已经缓存的资源不会被重新下载。为了发出预取请求,Marauder首先填充动态查询参数的值;
-
对于在应用程序缓存中未命中但与标记为无缓存的条目相关的文本文件请求,Marauder会发出一个对文本文件的请求,然后发出对其所有被引用子节点的预取请求。如果文本文件在某些预取资源之前到达,Marauder会小心地将应用程序显式发出的后续请求排队,这些请求已经有一个未完成的预取请求。通过这种方式,Marauder避免了重复请求和带宽浪费;一旦相应的预取响应到达,队列中的请求就会得到服务;
实验
应用程序加速
图14 说明了与当前应用程序所采用的默认缓存和预取策略相比,Marauder能够降低交互响应时间(IRT)。例如,在LTE网络上,Marauder 将一半的应用程序的IRT提高了 19.8-27.4%(或 0.58-0.81 秒);一半的应用程序的第 90 个百分位 IRT 改进为 29.7-43.5%(或 0.87-1.27 秒)。由于服务器的网络延迟较低,Marauder 在 WiFi 上的收益中位数和 90% 分别下降到 16.9-23.1% 和 26.1-33.2%。图 14 还显示,当用户会话之间的时间增加时,Marauder 的改进更加明显(即是前文的参数𝛿)。例如,在 LTE 上,随着𝛿 从 20 分钟增加到 4 小时,一半的应用程序的IRT 改进从 19.8% 增长到 24.4%。
Marauder性能深入分析
- 每个设计的效率:分别分析了JIT预取和Cache Refreshing的效果,后台缓存刷新以提高已缓存资源的命中率是 Marauder 收益最大的地方,在所考虑的 𝛿 值的中位数处提供 13.3-16.1% 的加速。相比之下,即时预取可提供 3.4-8.6% 的中值加速;
- 互动案例的测试:Marauder 优化的有效性受目标特定交互中的加载模式的影响。为了更好地理解这些关系,实验分析了当前应用程序的交互,并确定了影响 Marauder 提供的加速幅度的三种主要模式;
和先进方案对比
论文将 Marauder 与三种加速方法进行了比较:Paloma预取系统,以及应用程序支持的最激进和保守的预取策略。
总结
论文提出了一种移动应用程序加速系统Marauder,它综合利用缓存和预取技术,优化了TTL设置不当、缓存过时内容以及预取浪费带宽问题。同时,文章通过分析大量实验数据,得到了一些关键观察。相关实验设计非常巧妙值得学习。对缓存和预取这两种操作系统经典设计在应用程序加速领域做了深入分析,但是设计本身并不复杂。此外,从实现上来看,Marauder只是用上述优化的版本替换了大多数应用程序所依赖的缓存库,可以立即部署。
源代码和实验数据访问 https://github.com/muralisr/marauder
The End
致谢
感谢本次论文解读者,来自华东师范大学的博士生李文通,主要研究方向为跨设备资源共享、移动计算。