文摘
代码卸载是一个受欢迎的技术扩展自然功能的移动设备处理器密集型任务迁移到资源丰富的代理人。尽管多个平台能在学术界获得卸载,这些框架还没有渗透到这个行业。的主要原因之一是有限的实验在实际设置和缺乏可靠性、可伸缩性和选项分布。介绍了MobiCOP,卸载新代码框架与这些需求而设计的。它是一款新颖的设计完全独立的图书馆,并提供兼容大多数股票今天Android设备可用。与本地任务执行相比,MobiCOP提供17 x的性能改进和提高电池效率高达25 x,显示最低性能退化与不稳定的网络环境,和特性自动定量模块,允许它的服务器与扩展到任意数量的卸载请求。它兼容Android最相关的技术优化了繁重的计算(NDK和渲染脚本),迄今为止得到的移动开发者。我们希望MobiCOP将有助于移动代码卸载接近工业领域。
1。介绍
在过去的几年里,我们目睹了一个前所未有的增长,移动设备的普及。这主要是由于高端智能手机的需求增加,在新兴市场低成本设备的高可用性。事实是,这一趋势将持续下去,作为思科的预测表明,到2021年,将有116亿mobile-connected设备(约1.5人均移动设备)1]。有了这样的前景,硬件和软件制造商一直推动移动设备的边界进一步试图捕捉消费者的这种日益增长的质量。因此,多核处理器、高分辨率显示,强大的图形处理单元,多个传感器已经成为常态。然而,尽管巨大的进步在移动设备的整体功能,电池寿命一直在努力跟上。根据Sekar,“权力仍然并将仍然是一个一流的设计约束的继续推进移动技术”(2]。因此,功率优化一直在移动平台工程师研究的一个重要话题。作为回应,行业领导者谷歌和苹果最近推出新的操作系统特性意味着限制耗电应用程序的使用,从而延长电池寿命。例如,iOS 9引入了低功耗模式,可以手动启用,以减少电池消耗iPhone和iPad设备;Android棉花糖另一方面介绍了瞌睡,一组启发式意味着禁用某些特性,如网络或警报,如果没有检测到活动的设备。然而,一个常见的趋势在最近的这些创新是一切努力来解决这一问题已经完全集中在局部优化,留下云尚未开发的潜力。
云计算被广泛认为是下一代的计算基础设施,使强大的服务器和其他计算资源的需求(3]。移动云计算(MCC)特别是已被公认为一种有效的方式提高移动设备的功能。MCC,代码中卸载已被建议作为一种技术,增加了明显的移动平台的能力,以及他们的电池寿命4),透明的计算密集型任务迁移到一个资源丰富的离线代孕不受制于权力的限制。适合使用卸载是执行广泛的CPU或GPU计算任务,尽管如此,最近,迁移网络密集型操作已被证明能带来好处由于更可靠和更高的吞吐量特性的有线连接的服务器5]。然而,即使一个数量级的性能优势和电池的好处已报告两个数量级,卸载代码解决方案尚未出现在社区中广泛使用。
尽管有前景的结果控制的实验室环境中,我们认为,缺乏在真实场景中评估显示,有几个障碍有待解决的代码将会阻碍实际应用。这些解决方案允许我们集团的分析这些障碍分为三大类:可靠性、可伸缩性和分布。关于可靠性,依靠同步全双工通信,通常在整个持续时间的卸载任务,为现实环境是不现实的,移动网络也有强烈的倾向去间歇性地失败。多媒体应用的依赖非常大的文件大小,这个约束是严重限制6]。关于可伸缩性,大多数目前出版解决方案未能提供的证据支持多个客户端同时进行。事实上,对于一些架构,它强烈建议服务器和客户端之间的一对一的比例需要适当的操作。除此之外,我们知道的很少的工作,其中包括一个自主计算模块支持任意负载。最后,对于分布的目的,许多解决方案都是基于定制的操作系统版本,非常难以为普通用户配置和要求潜在受众自愿跳过最终安全补丁和功能升级。
在本文中,我们提出一个新的计算卸载平台叫MobiCOP(移动计算卸载平台)7]。与大多数其他解决方案,MobiCOP避免处理可能出现的分钟优化从迁移特定方法在任意位置,而是集中在整个长期的优化计算密集型任务出现在现代的应用程序。这个解决方案是专门设计来解决上面提到的三个约束条件。特别是MobiCOP的一个主要优点是,与所有其他已知的替代品,MobiCOP的客户端是完全独立的图书馆,是大多数股票Android设备兼容。因此,将其添加到现有的Android项目一样容易添加一个Gradle依赖性。服务器组件在另一方面可以通过一个公共AWS AMI,有意者可以拥有一个完全配置MobiCOP服务器实例在几分钟内。据我们所知,这是最简单的移动代码复制出售解决方案。
本文提出以下主要贡献。(1)它展示MobiCOP、新功能齐全的卸载代码框架,同时满足可靠性的要求,可伸缩性和分布在手机行业。(2)它提出了一种新的范式实现代码卸载,需要操作系统定制和与外部第三方工具的集成。(3)它引入了一个新的基于证据的决策引擎,使任意代码的执行时间的准确的预测最常见的场景。
剩下的纸是组织如下:部分2介绍了相关工作;部分3MobiCOP提出了一个详细的描述,我们的解决方案;部分4提出了多个评估用于验证的解决方案,提供了一个简短的讨论结果;最后,节5,我们强调MobiCOP的贡献和现在我们的结论和研究的影响。
2。相关工作
几个代码卸载框架显示在学术界提出了有前景的结果。在本节中,我们列举一些最著名的完全开发的代码把框架包括一个完整的端到端解决方案。
Satyanarayanan等人提出了薄云,网络觅食的延伸,旨在利用直接公共云的能力(8]。而不是在遥远的服务器上执行cpu密集型任务通过网络,他们建议使用附近的资源丰富的公共电脑可以访问通过短距离无线技术。卸载可以通过虚拟化。薄云预配置有多个基本vm功能所有常见的潜在客户所需的功能。那些需要更多的计算机资源和范围的薄云可以传输一个轻量级虚拟机覆盖,与它相关的基础,可以实现快速复制客户的环境,使它们之间的协同作用。虽然理论上听起来,这个解决方案需要大规模的薄云大规模基础设施还没有可用的今天。蘑菇等人另一方面认为薄云中间层之间起着中介作用的移动设备和云服务器。他们提出了一个“动态节能意识cloudlet-based移动云计算模式”(DECM) [9),它使用动态编程来确定哪些服务器,在一个广泛的和异构云,应该由客户端访问为了减少净能耗,因此实现绿色计算。然而,DECM只关注建筑模型并没有提供具体的实现。
最近,薄云的进化范式被建议的形式mobile-edge云计算(10]。在这个模型中,服务器位于无处不在的无线接入网络的边缘靠近手机用户补充他们的能力利用的资源遥远的云。边缘服务器可以卸载(部分或全部)计算云快速的方式,由于高吞吐量的使用有线连接,然后传递结果回客户机通过短程通信技术。不幸的是,目前多个mobile-edge计算架构模型存在(11),没有具体的实现是目前广泛使用。
符合的想法利用附近的计算资源,另一个提议使用卸载迁移可平行的资源密集型任务直接闲置移动设备连接通过一个特设网络。这种技术的一个例子是岩狸框架,android兼容基于Apache Hadoop MapReduce实现,允许跨多个附近运行的并行任务节点,也就是说,其他类似的设备在不远的附近可以通过短距离无线频道(12]。然而,性能在实际场景中仍然是一个问题,由于公共移动ad hoc网络的不可靠性,对进入网络,缺乏激励和MapReduce没有针对这种情况进行了优化。
钱和安德森提出玉(13),计算卸载框架针对运行Android操作系统的移动设备。这个框架减少耗电任务通过出售他们的能源消耗与Java VM服务器安装,通过使用远程过程调用(RPC)。它提供了一个简单的编程模型,使Android开发者创建任意远程对象通过实现一个Java接口。玉提供了一个运行时,它定义了三个主要组件:一个分析器,优化器和通信处理程序。性能分析包含两个子组件:一个程序分析器(估计给定远程对象)的能源成本和设备分析器(跟踪网络的可用性和吞吐量)。其次,优化器负责决定是否将一个远程对象根据分析器的输出。最后,通信层执行卸载操作通过实现suspend-wait-resume方案在客户端和服务器联系部署到另一个移动设备通过wi - fi和蓝牙。
移动到遥远的基于服务器的解决方案,布谷鸟使代码卸载通过扩展Android编程范式已经熟悉移动开发者(14]。在杜鹃,任务可能将封装在服务。捕获后,服务调用的框架和在本地或远程执行根据当前的条件。
毛伊岛是一个。净卸载代码框架,最大化节约能源(15]。它实现了代码可移植性利用的属性。净公共语言运行时。要求开发人员手动标注方法,可以卸载。通过反射之后,这些方法提取从一个客户端和一个服务器端解决使用输入分析器来决定是否出售。
克隆云是另一个代码把框架建立在一个定制的蛋糕(Android分支16]。这些修改是必要的框架来支持动态分析和迁移。不像毛伊岛,克隆云能够自动选择要卸载的部分代码不需要程序员干预。这是通过在一个静态分析器决定所有法律分割点在一定的约束和入口和出口之间的估计时间,没有卸载分区表示。通过应用程序级虚拟机实现服务器端执行,沟通是由一个移居者线程处理。
ThinkAir是另一个卸载代码框架,旨在解决毛伊岛的可伸缩性问题通过支持点播云资源分配(17]。它也解决了克隆云的应用程序,输入,和环境条件的限制,采用在线方法级卸载机制。ThinkAir处理可伸缩性通过创建一个完整的智能手机VM系统在云计算和提供一个接口,允许客户要求更强大或更大数量的虚拟机来处理最资源密集型的任务。方法容易被卸载是开发人员的注释。这允许在编译时代码生成器运行构建必要的客户端和服务器之间的通信层。
彗星探索新方法的执行代码卸载试验分布式共享内存(DSM) [18]。为此,作者通过添加几个虚拟机同步原语要利用DalvikVM延长了Android CyanogenMod姜饼中,这样就可以支持DSM。彗星在线程级别运行,允许同一个线程运行在两个不同的环境。然后建立一个全双工的字节流,让两个线程从一个环境迁移到另一个和分享他们的状态。
弗洛勒斯等人提出EMCO,卸载代码框架着重突出加强卸载决定利用众包和以证据为基础的学习方法在云中19,20.]。基于服务器的神经网络算法分析卸载客户端和使用它们的痕迹,推断if - then - else卸载规则,后来推到移动客户端通过GCM模糊规则。输入多个客户端因此可以用来开发高度准确的决策模型。
最后,戈登等人后退一步并提出另一种卸载建筑在他们最新的框架中,探戈。而不是依靠天生不完美的决策引擎,完整的应用程序在云环境中复制,同时运行在任何时候(5]。修改确定的线程调度机制允许两个环境在所有可能的情况下产生相同的输出。两个副本,最快的是领导者和一个驱动程序向前;上下文切换导致较慢的副本应该变得更快,领导角色交换通过作者所说的触发复制。
表1显示了上面提到的不同方法的一个总结。主要问题常见的所有以前的平台是非常没有证据是提供关于他们如何运作在现实生活中的场景,其中网络不稳定是常态和服务器流量峰值,是可以预期的。一般来说,我们注意到,许多这些框架的整合功能上发现桌面级代码卸载方案,,因此,他们不顾一些的在移动环境中最突出的问题。MobiCOP试图解决这些问题。
3所示。MobiCOP平台
3.1。动机
存在大量的研究在操作系统领域的需求所必需的最优移动出售解决方案的实现。许多证据的概念设计的分支的最新Android开源项目(AOSP)分支和添加一些特性这一目标,比如收集底层指标的执行任意的函数和DSM。然而,直到现在,做了很少的工作探索构建一个移动代码卸载方案的可行性与现有不变的移动操作系统。MobiCOP出生的渴望探索这种可能性。我们的主要研究目标是双重的:首先,我们寻求评估代码的健壮性卸载方案与标准Android API构建;第二,我们寻求解决当前可用的工程缺陷出现在移动代码卸载阻碍在实践中使用的解决方案。
这个研究表明可以构建一个相当健壮的功能齐全的卸载代码框架的Android操作系统无需修改操作系统。此外,它提供了一些设计方面的考虑,应该考虑在未来建设的卸载代码解决方案来提高整体质量,它列出了一些挑战需要克服如果我们寻求实现这些解决方案在实际设置。
3.2。设计概述
MobiCOP是一个全功能的代码卸载的框架,提供了实现这样一个系统的所有模块预计,包括远程执行环境,决策引擎,和通信层。它的目的是减少长时间运行的后台任务执行时间和功耗。
Android操作系统,延长后台任务应该由一个Android服务组件,以解耦的任务从一个活动的用户界面,让操作系统最终破坏活动回收内存没有阻碍了后台操作。此外,服务不太可能被摧毁在资源短缺的情况下比活动;因此,操作封装服务更容易完成。一旦定义的开发人员,一个服务调用它是相当简单的。这个过程的唯一需要注意的是,活动和服务作为孤立的组件;因此,为了传递参数从一个到另一个,开发人员需要手动输入参数传递一个接一个,使编组的Android操作系统。替代传递数据的方法,例如,通过静态变量,不推荐和认为是糟糕的实践,从操作系统不支持先发制人的资源破坏。
MobiCOP充分拥抱这个哲学和提供了两个service-encapsulated核心实现优化资源消耗和类似的接口为卸载任务。这给我们提供了两个主要的优点:首先,它允许我们为开发人员提供一个API唤起某种意义上熟悉标准的Android SDK;第二,它使我们能够克服在卸载框架的最大挑战之一:国家转移。自从毛伊岛,状态传输已经被认为是最大的挑战在卸载代码框架的发展。常用技术,解决这个问题涉及自动可以堆计算(16]:通过卸载任务可获得整个堆和发送到云计算。不幸的是,这需要大量的数据通过网络发送,特点,建议在不可靠的和昂贵的移动网络。一些研究者提出不同意味着限制国家转移,例如,通过静态分析相关的可执行代码(21)或通过分布式共享内存的实现(DSM) [18]。然而,这些选择是远不够理想,因为他们需要大量的处理或网络流量。
我们的实现需要退一步相比传统手动卸载框架和要求开发人员通过相关输入的任务将被卸载。而不利的乍一看,这种方法是相同的,Android开发者习惯于当安卓系统组件之间实现数据共享,从而凝聚很自然。,本地和服务器之间的数据传输环境也可以立即确定和保持在最低。
平台的接口也深深地集成与我们的决策引擎。通过数据作为一个散列映射框架,所有的输入数据都默认标记。这些信息可以用来做出准确预测任务的执行时间根据过去的证据,假设任务是确定的。这一点,再加上一个上下文和网络分析器负责评估网络的状态和吞吐量,允许我们做出有根据的决定最好的上下文执行给定任务优化性能和电池使用。
我们的平台支持的最后一个特性是能够支持并发执行和卸载的任务。虽然我们的背景和网络分析器能够正确评估网络的状态在任何给定的时间,是不可能保证网络质量将保持相同的整个生命周期的卸载操作。一旦操作成功地转移到服务器,可能是其最终的产出将无法达到客户端由于骤降网络可用性。默认情况下,我们的框架承认这些场景通过超时和落回当地实现如果结果未能及时到达主机应用程序;然而,在这种情况下,延迟将是不可避免的。它因此可以感兴趣的开发人员在本地和服务器上同时运行一个任务,以确保最佳的性能将会达到。这样,客户端将保留结果从最有效的上下文,尽管网络质量问题,尽管电池消费预计将略有增加。探戈是一个最著名的卸载代码框架功能并行任务执行(5]。一个用例,这是有关在处理冷启动新的应用程序安装。我们的决策引擎是基于过去的证据来决定最合适的上下文中运行的任务。如果证据说不存在(由于新安装或最终用户删除应用程序的本地数据),就不可能返回一个受过教育的猜测。在这种情况下,我们的框架总是默认并发执行,保证一个合理的性能和获取所需的数据开始未来的决策。从这里开始,我们将引用一个工作流的任务是在一个上下文中运行基于决策引擎的输出乐观和一个在他们两人同时运行并发。
3.3。体系结构概述
客户端库的重要部分围绕一个核心Android服务,负责处理传入的任务和互联平台的各种组件。每当用户分派任务这个服务时,它将查询决策引擎决定适当的执行上下文和是否应该合并执行任务。概述MobiCOP的工作流图中可以看到1和一个完整的架构图2。
MobiCOP与移动的通信层是建立在思想和设计在不可靠的网络条件下流量和功耗最小化。因此,它利用异步通信和可恢复的数据传输,以减少问题源于载荷转移中途打断,而过早关闭套接字。MobiCOP定义两个沟通渠道,一个专门为控制消息的传输协调卸载任务的状态和转移的第二个优化大型有效载荷。为了减少资源消耗,这是决定控制消息的传输基于谷歌重火力点上游消息传递技术。上游传递是一个XMPP通信通道,允许Android客户重用相同的套接字使用推送通知和继电器小载荷的处理任意接受者通过Google的基础设施。其主要优点包括插座重用提高电池寿命和资源优化的异步本性XMPP。
另一方面,以确保最佳的性能和可靠性传输的大型有效载荷,它是决定建立第二个通道上的基于http的可恢复的数据传输技术。这个选择的主要原因是允许应用程序恢复转移从他们断开连接的网络中断。我们决定对建设一个自定义的协议,以确保MobiCOP与网络的可用性在公共环境中配置为限制特定的端口(例如,学校,机场)。上传,我们的解决方案利用摘要协议可恢复的上传。摘要是一个开源的基于http的通信协议旨在提供一个统一的解决方案来处理中途连接失败的问题。它提供了一个健壮的框架,将大型有效载荷分成更小的包,组装的服务器在发送完所有的包,和错误处理。下载,我们利用元数据范围中定义的HTTP,它允许静态文件服务器恢复下载从任意抵消定义的客户端。这两个解决方案的工作,所有大型有效载荷必须首先被记录到磁盘文件。这有两个主要的好处:第一,它允许流从磁盘而不是记忆,因此减少了应用程序的内存占用和风险的“内存不足”的错误;第二,它允许推迟的处理结果,对非关键任务运行一个有用的特性,当最终用户是在一个不同的活动。
区分时使用的通道时,我们考虑到了谷歌4 KB的限制通过上游传递消息传输。如果合并后的任务大小输入设置加上相关的元数据定义为MobiCOP不超过4 KB,所有的数据都是通过第一通道单独发送;否则,服务器/客户端要求等相关联的输入/输出数据发送通过第二通道之前。
MobiCOP的服务器组件定义了四个不同的模块:一个公共接口,中间件,弹性云组件,和这个Android服务器环境。公共接口公开的服务的客户可能会相互作用:一个XMPP端点连接到Google的基础设施来接收上游消息,摘要服务器来管理大型有效载荷的可恢复的上传,和一个静态文件服务器范围符合HTTP头规范来处理大型有效载荷可恢复的下载。把请求传递给中间件负责管理未决任务的状态和完整性检查Android执行环境。后者目前基于“Genymotion需求”,提供虚拟x86兼容安卓环境之上的Amazon Web服务的基础设施。
几个备选方案被认为是在云中运行Android,包括与Android x86和运行自己的自定义服务器Ravello系统Android仿真技术(22),然而Genymotion设法表现明显优于其他各种性能测试。Genymotion需求也给我们的好处使与其他AWS服务的集成,比如AWS自动伸缩功能。后者是我们的架构的一个组成部分,因为它允许我们安卓虚拟机的数量规模适应卸载请求的数量被收到在任何给定的时间。此外,备用实例删除一旦流量减慢,这让我们节省货币成本。额外的自动伸缩功能的好处包括提高容错、自动伸缩功能自动检查当前运行实例的状态,重新启动他们,以防他们变得反应迟钝,和提高可用性,因为自动伸缩功能创建额外的实例在地理区域网络交通繁忙。
开发者需要预装应用的APK Genymotion点播安卓虚拟机平台的操作。这让我们复制相同的逻辑,客户端不需要转移可执行代码或其依赖项。
一旦任务完成在服务器,其结果是通过重火力点推送通知发送回客户机。如果任务的输出超过4 KB,数据存储在一个文件并通过静态文件服务器转发。目前客户端接收数据,任务的结果转发到Android应用程序通过一个广播,后来被一个Android广播接收器,它定义了如何处理结果。我们的框架的设计的一个主要后果是它迫使开发人员代码以线程安全的方式。因此,MobiCOP不支持midtask客户机-服务器通信(只有轻量级状态通知从服务器到客户端为了支持简单的特性,比如进度条)或intercontext同步(例如,共享锁)。这是有意的,因为这些特性容易并发错误和现代移动api抽象他们多年。
总之,一个标准的MobiCOP卸载工作流操作如下:每当MobiCOP决策引擎决定卸载任务,其输入数据的大小来衡量。如果以上4 KB大小,激活文件同步模块和输入参数传输到服务器通过摘要(图2,一步)。否则,跳过这一步,我们继续联系服务器通过FCM(图2、步骤和)。一旦服务器接收请求将代码(图2,一步)、中间件应用程序日志条目(图2,一步),并将其转发到AWS自动伸缩功能模块(图2,一步)。这个模块将消息传递给Android操作的运行时之上Genymotion(图的需求2,一步),还会产生附加实例如果服务器负载过高或终止一些相反的情况。一旦任务完成,通过推送通知消息发送回使用重火力点下游消息(图2,一步)。在这里,它是可能的消息暂时扣留谷歌如果客户不能达成。这可能发生,如果客户机的连接丢失或如果用户关闭设备。在这种情况下,FCM可获得该设备将等待再次转发之前(图的结果2,一步)。当客户端收到消息时,文件同步模块可能再次需要从静态文件服务器检索额外的数据如果输出数据不符合在FCM包(图2,一步)。如果情况不是这样,这一步是跳过。最后,一旦所有的结果都可以在客户机上,框架发出一个广播通知应用程序操作完成(图2,一步)。
3.4。应用程序编程接口
卸载都封装在一个可运行的任务是从一个超类的API(图3)。这个类提供了实用方法用于访问Android上下文和部分结果。它定义了一个抽象方法需要实现的开发人员。在这里,他们可能包括任何自定义的逻辑。输入和输出参数封装在一个通用的对象通过API,包括二进制序列化逻辑元帅的参数从移动端到云透明的。这个对象可以填充任意原语的词典及其对应的数组,采用一种模式非常类似于Android的意图。为了在客户机和服务器之间传输数据,所有参数序列化使用谷歌的协议缓冲区,一个轻量级的平台无关的二进制序列化技术。
一旦定义这个类,用户只需要声明一个输入集和通过对(输入,可运行)框架(图4)。这将反过来立即产生一个操作ID的开发人员可以使用关联未来结果各自的任务。如果在乐观的模式下,图书馆将决定是否在本地运行的代码或卸载它,决定对开发人员透明;如果并发模式,任务将同时运行在上下文,除非网络条件阻碍卸载。在后一种情况下,同步机制保证了只有第一个收到的结果为一个特定的操作传送回到应用程序。在客户端完成之前收到来自服务器的结果,后者就会被忽略掉。否则,客户的结果将被忽略。在这最后的情况下,重要的是要强调运行操作不会被强制流产为了防止潜在的失败来清理资源。相反,一个线程中断标志将被触发,鼓励开发人员检查为了过早终止手术。
最后,结果由当地广播接收器接收。决定使用这个机器人功能收集结果是基于这样的事实,用户可能任务完成前退出应用程序。他们应该这样做,一个广播接收器允许处理结果即使UI不可见或如果应用程序已经终止的操作系统。如果Android清单中声明,它甚至允许接收和处理结果后重新启动。
3.5。决策引擎
MobiCOP决策引擎由两个模块组成:服务质量(QoS)监视器和一个代码分析器。QoS组件负责分析网络,也就是说,跟踪其可用性,延迟 ,和传输速度 。wi - fi连接,通信速度采样时刻设备连接到一个新的网络,然后定期定期。移动网络,另一方面是棘手的问题。我们决定寻求另一种方法在这种情况下,为了避免产生不必要的成本转嫁给最终用户。因此,网络速度估计是基于记录的平均传输速率连接的亚型(LTE、GPRS、边缘等)。
代码评测器负责跟踪过去的任务执行和预测未来任务的运行时间。这个模块的操作是基于启发式,两个任务共享相同的逻辑,输入参数将同时完成。它的实现是呈现可能由于我们的编程接口特性。对于每一个任务 ,其输入设置 转换成向量通过应用功能每个元素的 。在特定情况下,输入对应的散列映射开发人员需要通过框架。不同的输入值集的散列映射的键-值对。然后我们定义如下:
让的归一化向量相等 。让代表着秒,任务的执行时间代表一个数据集的大小字节。每当一个任务完成后,元组 由客户端存储在kd tree,作为其搜索键。一旦足够的数据记录,对新到达的决策引擎可以作出准确的预测任务。让是一个新到达的任务。决策引擎执行一个最近邻算法来找到那些记录的向量最像 。让之间的距离的倒数和 ;我们可以做一个预估作为
迄今为止,我们的算法显示良好的结果在我们的测试中,但它有限制在处理不确定性算法和向量维数高。同时,我们不得不限制的大小KD-Trees防止积累过多的开销。使用服务质量经理和代码分析器子组件,这个决定将由以下是正确的:如果两个(我)一个好的网络连接可用(wi - fi: RSSI≥82−dBm;移动网络:ASU≥5)。(2)下面的不平等是正确的: 的价值是一个任意的乘数目前默认设置为1.5,根据模型推荐(23]。
4所示。结果与讨论
证明“的目标,MobiCOP经历了各种各样的测试场景。包括比较的微基准测试的目的与其他解决方案在稳定和不稳定的网络连接,服务器压力测试评估我们后台的鲁棒性,和macrobenchmarks的形式与实际商业应用的集成。测试是在低端和高端Android移动设备。对于低端,我们使用了一个联想A319双核1.3 GHz Cortex-A7 CPU和512 MB的内存;对高端,我们使用一个三星Galaxy S5四核2.5 GHz金环蛇400 CPU和2 GB内存。服务器组件部署在一个AWS m4。超大实例上运行Genymotion需求与Android 6。
在所有的实验中,我们测量了两个指标:性能和能量。测量电池的消费中,我们使用一个季风电力监控设备。对于所有基准测试,我们比较这两个指标在执行本地执行当卸载任务。潜在的移动代码卸载技术在很大程度上取决于他们使用移动网络技术,它影响吞吐量和能源(24]。因此,我们考虑下卸载wi - fi连接和3 g移动网络。
最后,我们评估易于使用和采用将MobiCOP-based移动云计算任务交给一个先进的计算机科学工程大学课程,要求学生在该平台上他们的意见。
总的来说,对于我们所有的实验中,通过MobiCOP卸载导致显著提升性能和能源相比本地执行。可伸缩性测试和易用性评价也积极。
4.1。微基准测试
微基准测试用于评估MobiCOP被选中代表MobiCOP可能最常见的用例。最常见的场景是计算一个标准的Java算法。然而,随着MobiCOP主要集中在CPU或GPU-intensive长时间运行的任务,我们特别关注了Android的技术专门为计算密集型应用程序。有鉴于此,我们包括微基准测试算法利用Android NDK(使与优化的C / c++代码)交互和渲染脚本(框架并发CPU、GPU和DSP计算)。重要的是要强调是多么关键的卸载框架支持这些技术作为现代商业应用程序利用密集计算极有可能利用至少其中之一。我们也考虑微基准测试应用程序需要大量的状态传输客户端和服务器之间高网络流量条件下评估行为。对于每一个四类,我们考虑以下具体的基准。
(我)纯Java的计算: 皇后问题 。所有人的任务是列举配售有效的皇后在一个×棋盘上,没有女王的另一个范围。
(2)NDK计算:国际象棋引擎(8层)。任务是计算最优移动在一个国际象棋的游戏电脑考虑提前8可能的举措。国际象棋引擎选择这个微基准测试是在c++中实现并通过Android NDK界面上的。
(3)Renderscript计算:曼德布洛特分形。生成的任务由曼德布洛特通过一种算法实现分形Renderscript和可视化在3000×3000的形象。
(iv)计算涉及交通拥挤:视频转码。代码转换的任务由WebM视频到一个MP4等效利用FFMPEG。在这个实验中使用的视频是48秒长,4.5 MB的大小,它需要转移全部开始时和结束时卸载任务。
所有这些基准是基于网上开源实现。图5稳定的网络条件下显示了结果。
总的来说,所有指标表现出实质性的改进,当卸载在wi - fi和3 g移动网络。唯一的例外是总执行时间和电力需求Renderscript基准在高端设备。主要原因是任务本身太短的时间相比,转移输出文件返回到客户机。一般来说,卸载任务需要完成的时间越长,就越明显MobiCOP的好处。
同样重要的是充分证明MobiCOP执行在不可靠的连接。很难建立一个可再生的实验不可靠网络在现实环境中;因此,我们决定模仿一个不稳定的连接路由移动设备的网络连接通过一个代理配备网络调节能力。查尔斯对于这个实验中,我们使用的是代理软件和配置它来模拟一个缓慢的3 g连接包传输失败率为1%每10 KB传播。传输文件数兆字节大时,这实际上导致,而频繁的断开连接。由于这个原因,这个实验是特别相关的计算需要大量的客户端和服务器之间传输数据。因此,我们只显示结果为一个基准涉及数据交换(皇后)和一个涉及大量的数据交换(视频转码)。结果如图所示6。
所有指标几乎没有变化的情况下所需的状态转移很低。差异变得更加明显,当载荷大,视频转码的基准。同时电池和性能确实变得更温和,因为增加了延迟和传输时间,MobiCOP仍然设法超越当地执行以公平的优势在低端和高端设备。
4.2。可伸缩性测试
如前所述,MobiCOP旨在解决可伸缩性问题通常存在于当前的代码把解决方案。为了证明可伸缩性,我们执行压力测试实验中挑选三个,在我们发送不同数量的卸载一个要求皇后问题( 这个实验)在30分钟的时间。模拟不规则速率请求接收在实际环境中,我们使用一个泊松过程3、6和12个每分钟的请求。自动伸缩功能实例复制政策可能调整根据开发人员的具体需求;然而,在我们的例子中,我们设置环境时双服务器实例的数量总体CPU工作负载将超过50%,在所有实例终止四分之一的实例时CPU的负载会低于25%。
图7从这些测试显示了结果。左边的图表展示的发展在整个测试Android实例的数量。右边的图表显示平均响应时间间隔的演变,Android实例的数量是恒定的。作为一个参考点,一个孤立的请求的响应时间约为53秒。
的评价,我们可以确定三个场景。第一个每分钟请求(3)需求的情况下调整初始条件的云平台。事实上,不需要额外的服务器实例运行Android,平均响应时间是保持稳定的整个执行测试。每秒请求第二个场景(6)代表一个案件需求有点太高了云平台的初始条件。因此,最初欠佳的响应时间。Android平台开始增加的情况下,响应时间开始往第一个测试的预期值。最后,第三个场景(每分钟12请求)是一个案件的需求完全崩溃的云平台由于其初始条件。因此,有限的时间,服务器性能变得很差。为了能够满足这个交通,平台积极尺度Android实例的数量,直到服务器恢复他们的能力来有效地处理它们。之后,安卓系统实例的平台开始减少,直到需求达到平衡与平台的容量和响应时间稳定在期望值。 In this last scenario, it takes our server about 13 minutes to adapt itself to provide an optimal response time for the offloading request. Nevertheless, we must highlight that it is possible to further decrease this interval by configuring Auto Scaling to increase the number of server instances when under high workload conditions by a factor greater than two.
除了响应时间的进化,我们使用第二个指标,吞吐量,来评估我们的解决方案的可伸缩性。吞吐量可以被定义为系统处理请求的速度。根据小定律,我们可以计算系统的吞吐量如下: 在哪里交易正在处理的平均数量,平均响应时间,是系统的吞吐量25]。表2在我们的实验中显示了结果。
从表中,我们可以看到,相对较低数量的并发请求的吞吐量增加线性。然而,鉴于过程的性质(高CPU使用率几乎一分钟为一个孤立的请求),我们可以看到,系统很快达到其吞吐量上限6个并发请求。额外的并发请求快速降解系统的吞吐量如果Android实例的数量保持不变。然而,我们的系统自动定量的能力确保了高吞吐量的需求由自动实例化附加的Android实例在云上。
我们可以观察到的结果,MobiCOP可以适应不同层次的需求,增加或减少Android实例的数量根据其需求。注意的性能是很重要的一个特定应用程序的可伸缩性的政策可以改善通过详细分析MobiCOP目的的用例。
4.3。实际用例
MobiCOP设计与生产就绪的应用程序集成的目的。因此重要的是要证明它可以成功地融入工业水平软件与复杂的工作流程和用例。记住这一点,我们现在将显示两个macrobenchmark专业应用的例子,从MobiCOP能够获得好处。
4.3.1。画馆
画馆是一个图像处理应用程序,利用机器学习技术学习模式特定的画家的风格和将它们应用于任意图像为了重绘和获得一个油画等价的。
画馆的算法是基于三个连续步骤(图8)。首先,一个颜色梯度计算输入图像中的每个像素。然后,梯度分为集群的则算法。最后,一个过滤器应用于模仿一个画家的笔触。画馆设计在离线操作设置;因此所有的本地处理。由于性能的原因,Galerie充分利用OpenGL利用设备的GPU,除了CPU,以增加算法的处理速度。因此,图像变换非常CPU GPU-intensive,所以它需要几分钟来完成(更低端的设备),在此期间大量的电池耗尽。
MobiCOP介绍自己是一个很好的机会格兰特Galerie能够提高性能和电池寿命在网络可用的设置,而无需牺牲离线支持(尽管在这种情况下MobiCOP不会授予任何额外的好处)。此外,MobiCOP允许这无需重写算法实现复杂的逻辑在服务器环境。结果当运行Galerie转换748×748图像1.3 MB的大小,和没有MobiCOP,如图所示9。
MobiCOP给Galerie出色的性能和电池获得低端和高端设备。虽然为高端设备性能提升不明显,特别是3 g连接,减少电池消耗仍然明显由于剩余设备闲置在操作。
考虑到Galerie集约利用GPU和Android在AWS没有物理支持GPU实例(他们被CPU仿真),我们也感兴趣这一事实如何影响我们的平台。我们也采取了单独测量的执行时间——(cpu密集型)和中风过滤器(GPU-intensive)流程在执行算法局部(设备物理GPU)和卸载时执行。结果如图所示10。
结果表明,GPU的相对收益过程的收益小于CPU进程,GPU的过程仍在卸载时更快。从这些结果,我们得出结论,即使访问物理GPU限制为Android在AWS实例,任务仍然是在服务器上执行得更快。然而,AWS最终应当添加GPU支持Android,我们期望结果变得更加有前途。
4.3.2。传热性能
传热性能是一个预警医疗应用程序,旨在检测可能的神经系统并发症(如脑震荡、创伤性脑损伤)通过分析病人的演讲(26,27]。具体地说,它要求病人做持续的元音测试(说“啊”尽可能长时间),记录音频,然后提要深度学习神经网络的语音样本处理样品,并将脑震荡概率。持续元音测试是一种常见的语言病理学家检查要求。示例应用程序的屏幕截图如图11。
深入学习算法是最适合图像识别应用程序中,语音样本首先被转换成声音之前美联储到网络。传热性能的神经网络是非常复杂的,因为它试图检测模式,人类很难注意到。为此,组成的一个复杂的架构十平行50-layer深残余神经网络。输出然后凝聚成一系列连续的完全连接层之前提供一个最终的结果。与MobiCOP卸载时,谱图作为输入通过网络发送到服务器,震荡概率是发送回客户机的操作结果。
由于模型的复杂性,导致神经网络最终大约250 MB的大小,需要超过1 GB的内存加载和执行在一个移动设备。这使它适合低端设备无法满足这些最低规格,运行这个模型会导致内存不足的错误。即使在高端设备,一个单一的语音样本处理将接管两分钟完成,再次消耗大量的电池。
MobiCOP有两个传热性能的主要好处。首先,它允许高端设备获得性能和电池效率网络可用时。第二,它使传热性能与低端设备未能满足其最低要求规范,虽然只有在设置网络连接。仍然限制在特定的环境比根本没有,所有上述实现用最小的编程工作,不需要移植模型server-compatible神经网络框架。结果如图所示12。
由于MobiCOP,传热性能的性能提高了4倍,能耗降低了6次,它的目标受众是大大扩大了允许所有者低端设备的使用应用程序。
4.4。准试验与移动开发者
经常被忽视的一个方面把框架代码是多么困难的第三方采用的平台。这是一个非常重要的方面寻求确认任何报道时需要考虑的结果。为了评估MobiCOP的易用性,我们寻求援助的学生IIC3380移动平台研讨会类在智利天主教大学。这个班的学生被教导基础和先进的Android应用程序开发和移动云计算的概念整合。它是一种先进的课程由研究生和高级本科生。
在2016年的这个类的实例,14岁参加学生分手在四个不同的团体,负责复制皇后问题基准和视频转码基准。此外,每组被分配了一个最具代表性的框架,把环境和要求做与他们相同的任务。所选框架这个任务在毛伊岛,彗星,探戈,EMCO。学生被期望与MobiCOP进行比较。由于缺乏文档关于这些框架,也鼓励学生直接联系各自的作者寻求帮助。在MobiCOP方面,学生被授权访问存储库持有MobiCOP代码和女王基准的例子。他没有给出进一步的帮助和文档。
的任务是发放在学期的开始和结束时到期。三个经验丰富的助教随时可用在车间指导学生。的任务,所有组织都具有繁殖能力的两个基准与MobiCOP在他们的环境中很少的困难。然后进行调查来收集学生的意见各自的框架,它允许我们做一个定性评估MobiCOP开发人员的经验。的一个团体报道如下:
MobiCOP的安装简单。[…]框架的实现相似Android意图是如何工作的,因此它很容易习惯。
一个小组发现他们分配框架和MobiCOP共享困难同样低的实现:
MobiCOP抽象卸载并创建一个接口类似于任何依赖于回调函数的异步任务。[…][EMCO和MobiCOP)很容易被包括到任何应用程序。
总体而言,MobiCOP被发现提供的福利优越:
关于实验和基准,EMCO有效地提供了几个优势相比,本地代码执行,但相比是小巫见大巫了性能提出MobiCOP框架。
然而,MobiCOP并非没有批评。缺乏与配置服务器文档和严重的困难是反对的。然而,这些评论被带到心脏和问题解决发展中一系列短暂的一步一步的教程和分发AMI AWS MobiCOP完全配置的服务器上,允许复制在几分钟内(这不是可用的实验和所有服务器基础设施配置必须由手工完成)。
EMCO之外,然而,我们的学生发现很少的成功复制其他框架。安装说明要么是不存在的,不清楚,或者极其严格的(即。,only taking into consideration specific Android models), and not every author answered their requests for assistance. At the end of the semester and despite several attempts, our students were unsuccessful in replicating MAUI, COMET, and Tango. While other authors have managed to use them in their experiments, this indicates that the average code offloading framework requires highly specialized knowledge of the mobile ecosystem to be successfully reproduced.
5。结论
MobiCOP从头设计专门解决三种常见缺陷经常发现在其他移动代码卸载框架:可靠性、可伸缩性和有限的分销或复现性。而不是提供一个通用方法级卸载框架,忽略了流动性的各种约束,MobiCOP基于标准Android实践提供了一个编程模型和概念给开发人员完全控制任务的迁移过程。从这个角度来看,我们的方法是类似的杜鹃。此外,MobiCOP设计与公共IaaS提供商完全兼容,允许总复制不需要物理访问服务器。
许多其他方法可用在学术界中理论测试时对一个设备和一套操作,但小信息作为他们的行为在处理多个请求卸载过一段时间。框架如ThinkAir认识到需要扩展迅速,但是很少有人把这一要求在他们的设计。
分配的问题也常省略。许多先前的框架只有定制的安卓版本上工作,妨碍采用公众。即使一个成功复制他们在个人设备上,他们将对一些严重的约束,将质疑他们的整体效益。首先,基于一个定制的操作系统版本,几乎没有关于安全保证;此外,安全补丁,系统更新和新的api出版标准的Android版本将不可用。MobiCOP,另一方面,提供了创新的实现是完全包含在一个库兼容所有的Android版本,API 17岁及以上水平。集成到任何项目非常简单,只需添加一个Gradle依赖性。服务器复制同样简单,多亏了AWS AMI存储库。
总的来说,MobiCOP结果非常积极的在整个光谱的测试进行。一般来说,卸载代码框架的好处越来越明显,当目标长时间运行的任务在稳定和高吞吐量的网络连接。MobiCOP仍然是这种情况:一个任务花几分钟来完成,它成功地显示了更好的性能相比,低端设备的17倍和25倍减少电池寿命损耗。尽管性能差异不太明显,当比较高端设备,电池仍然重要,甚至外部网络的理想条件,结果仍然非常有前途。在我们的视频转码基准,MobiCOP仍然执行12次比本地执行在3 g连接,和模拟网络中断只有退化结果小于10%。传统的代码相比,这是一个重大成就卸载的解决方案依赖于持续的全双工的套接字通信,网络错误会立即引发当地执行回退。相反,我们的异步消息传递系统允许最低网络流量,没有引发重大的开销在客户机上有限的资源。
在需求端Genymotion允许我们利用AWS套件软件工具的全部功能,进一步增强MobiCOP的能力。从今天开始,只有AWS EC2和自动伸缩功能被集成到MobiCOP。仅这一点就已经批准了我们的平台重要的鲁棒性与服务器实例完整性检查,自主计算功能,和部署服务器的能力需求最高的地理位置附近。预计与其他AWS服务的集成,如RDS或S3,将进一步增加MobiCOP的能力。
除此之外,事实上,我们整个解决方案是完全包含在一个图书馆为服务器为客户机和一个AMI,大大增加了目标受众为我们的技术。我们的解决方案不需要任何操作系统定制和添加第三方工具来构建系统。MobiCOP只是作品,大多数Android设备(智能手机、平板电脑、电视、嵌入式设备,等等)是兼容的。迄今为止,学生给我们好评MobiCOP的可接近性,但进一步的工作仍需要进一步简化开发人员的经验,例如,通过添加一个更好的错误报告系统(指导用户的错误配置)和通过一个正式的文档公开可用。
未来工作MobiCOP平台目前涉及三个主要领域。首先,支持异构云资源(需要添加28]。MobiCOP的一个主要限制条件是,它假定为卸载所有可用的服务器拥有类似的硬件特征。因此,决策引擎假定一个给定的任务将相同数量的云不管完成服务器它结束。我们正在致力于改善决策引擎来考虑这个变量,构建一个自定义负载均衡器,更好的匹配传入的任务服务器更适当的处理。
第二,我们正致力于将最先进的环境敏感功能添加到平台,包括兼容直接代理人如薄云和边缘服务器。这可以极大地提高MobiCOP的整体性能,允许直接服务器处理请求卸载在贫困或不存在的网络条件下,最小化需要引发当地回退一个卸载的决定后,和显著减少延迟29日]。在未来,我们希望MobiCOP能够在运行时动态选择哪些节点应该出售给几个可供选择的可能性。
最后,我们正致力于实现一个更健壮的安全协议之上MobiCOP保护平台恶意卸载请求。目前,没有实现身份验证机制,因此服务器是特别容易受到拒绝服务(DOS)攻击。进一步的工作是要尽量减少这种可能性。
随着越来越多的创新移动应用程序需要深加工能力,越来越多的潜在的用例可能受益于卸载出现。给几个例子,我们可以强调以下几点:(我)图像处理(例如,对象识别、图像滤波、人脸识别);(2)多媒体处理(例如,视频转码,语音识别);(3)文本处理(例如,机器翻译、自然语言处理、文档分类);(iv)人工智能(例如,视频游戏AI);(v)模拟(例如,蒙特卡罗模拟);(vi)安全(例如,病毒扫描);(七)物联网(例如,处理传感器数据)。
我们希望MobiCOP将有助于进一步卸载的趋势,这样更多的开发者可以获得这种技术并将其集成到他们的应用程序提供更好的用户体验和电池效率。
的利益冲突
作者宣称没有利益冲突。
确认
这部分由DCC-UC科研资助工作,CONICYT-PCHA /国家博士学位/ 2016批准号21161015,为研究和AWS云学分。作者还要感谢的作者画馆应用程序(胡安·安东尼奥·Karmy和菲利普Balbontin)和传热性能的应用程序(Bryan(宁)夏)授予他们访问代码库。最后,作者要感谢所有的学生从IIC3380移动平台在智利天主教大学参与这个研究项目。