Python多处理应用程序的远程透明执行及性能评估

⇒⇒未来一代计算机系统140（2023）436Python多处理应用程序的透明无服务器执行AitorArjonaBazi，GerardFinol，PedroGarcaLpez西班牙塔拉戈纳Rovira i Rovili大学ar t i cl e i nf o文章历史记录：收到日期：2022年收到修订版2022年10月26日接受2022年2022年11月8日网上发售关键词：透明访问透明无服务器FaaS多处理并行编程a b st ra ct访问透明性意味着使用相同的操作访问本地和远程资源。通过透明性，未经修改的单机应用程序可以在分散的计算，存储和内存资源上运行。通过透明性隐藏分布式系统的复杂性将带来巨大的好处，例如在云中灵活的分散资源本文提出了一个性能评估，我们评估的可行性，访问透明度超过国家的最先进的云分解资源的Python多处理应用程序。我们已经将多处理模块与一个实现接口，该实现透明地在无服务器函数上运行进程，并将内存中的数据存储用于共享状态。为 了 评 估 透 明 度 ， 我 们 在 云 中 运 行 了 四 个 未 经 修 改 的 应 用 程 序 ： Uber Research 的 EvolutionStrategies ， Baselines-AI 的 Proximal Policy Optimization ， Pandaral.lel的 Antrame 和 Scikit Learn 的Hyperparameter tuning。我们比较了使用我们的库在分散资源上运行的同一应用程序的执行时间和可伸缩性，以及大型VM中的单机Python多处理库。对于相同的资源，尽管远程通信的开销很大，但有效地使用消息传递抽象的应用程序可以获得类似的结果。其他共享内存密集型应用程序由于高远程内存延迟而无法执行结果表明，Python©2022作者（S）。由爱思唯尔公司出版这是CC BY许可下的开放获取文章（http://creativecommons.org/licenses/by/4.0/）中找到。1. 介绍Coulouris等人[1]将透明性定义为“对用户和应用程序员隐藏分布式系统的复杂性”。访问透明性允许在分布式环境中执行未经修改的并行代码，其中资源（CPU，内存）分布在许多机器上，但访问时就像它们被安排在单个本地机器中一样。本文的动机很简单：低延迟分解完全透明。网络延迟[2，3]的下降趋势表明，资源分解越来越可行，这为在未来几年实现访问透明度提供了机会[4云中的资源分解一直是当前无服务器服务（如功能即服务（FaaS）或对象存储）提供的灵活扩展模型的关键。无服务器服务还*通讯作者。电子邮件地址：aitor. urv.cat（A.Arjona），gerard. urv.cat（G.Finol），pedro. urv.cat（P.G.López）。已被证明对大规模并行计算应用程序[7，8]甚至大规模大数据处理[9]有效如果我们可以对本地和远程资源使用相同的操作，而没有显著的性能下降，那么就有可能统一本地和远程编程范例。在这种情况下，开发人员的生产力将大大提高，因为透明性将促进并使分布式系统更容易编程，从而使特定中间件的使用变得多余。此外，我们可以移植遗留的单片应用程序，并在云环境中使用灵活的资源对其进行扩展。可以避免软件现代化或架构重新设计的新迭代，从而为工程师节省维护成本和时间。通过透明性，资源可以适应计算密集型应用程序，以处理比单个机器可以承受的更大的工作负载，而不必修改底层代码或架构。事实上，在欧洲项目Horizon 2020 Cloudbutton中，我们的目标是过度简化和民主化使用1https://cloudbutton.eu。https://doi.org/10.1016/j.future.2022.10.0380167- 739 X/©2022作者。由爱思唯尔公司出版这是CC BY许可下的开放获取文章（http://creativecommons.org/licenses/by/4.0/）。可在ScienceDirect上获得目录列表未来一代计算机系统期刊主页：www.elsevier.com/locate/fgcsA. Arjona，G. Finol和PG 洛佩斯未来一代计算机系统140（2023）436437Fig. 1. 使 用 多处理的前100个最受欢迎的GitHub Python存储库的主要多处理抽象的使用百分比。使用无服务器技术进行科学计算。Cloudbutton[7]的文件。他的学生希望他们可以因此，透明度是一个重要的考虑因素，因为数据科学家目前使用的许多工具都是难以并行化或迁移到云中的遗留应用程序。此外，数据科学家不太可能了解云技术。实现访问透明度可以毫不费力地释放云灵活和无服务器资源的潜力，从而有效地加快科学计算管道的速度。尽管如此，分布式系统社区一直在批评透明性的概念。原因是过去深入研究的分布式共享存储器（DSM）[10]受到复杂性的困扰和性能问题，这使得透明度难以实现。Waldo等人[11]在1994年已经讨论过，在面向对象编程的上下文中，将远程对象当作本地对象使用是不正确的，并会导致性能问题和普遍的不可靠性。尽管作者在他们的文章中没有明确讨论访问透明性，但他们的结论表明，远程内存访问延迟和部分故障使完全透明性变得不可行。对透明性的主要批评是远程内存永远不会像本地内存一样快。然而，并不是所有的并行编程模型都需要密集访问共享内存。相反，许多并行应用程序只依赖于通信和同步原语，可以有效地分解。在这一行中，Python编程语言使用进程来实现真正的并行性。Python多进程中的共享状态主要包括消息传递（Pipes，Pandemes）或对其他进程的远程调用（Managers）。为了加强这一点，我们分析了GitHub上使用Python多处理的前100个最受欢迎的存储库，并发现管理器和管理器是状态共享最常用的抽象（图1）。①的人。在这方面，DSM造成的问题和限制将不适用，因此透明地使多处理Python应用程序适应分布式环境更加可行。本文介绍了一项性能研究，以评估无服务器函数的固有可扩展性，以及分解和一致的内存存储组件，是否能够在大规模分解的无服务器计算资源上透明地运行未经修改的Python多处理我们希望以相同的工作负载运行相同的应用程序加速比、并行性以及确定迁移到分布式环境可能产生的开销。为此，我们扩展了Lithops无服务器计算框架[12]，其中包含一个完全实现Python多处理接口的模块。这种重新实现利用了进程的无服务器函数和Redis数据库的有状态多处理抽象（共享状态，队列，锁）。.）.使用多处理库编写的Python应用程序可以透明地移植到云，只需更改import语句。对于性能研究，我们使用了四种科学应用程序-利用Python多处理并行的方法：进化策略，邻近策略优化，Scikit-Learn网格搜索和Pandas嵌套。对于其中的每一个，我们都将其在AWS EC2中当前可用的VM上的本地执行与其在AWSLambda上的等效执行进行了比较，同时保留相同的代码，以评估应用程序是否可以使用无服务器的灵活资源进一步扩展，尽管会产生限制和开销。结果表明，使用无服务器资源有效地运行本地并行Python应用程序. ），以便执行。相反，由于远程内存的高延迟，大量使用共享内存抽象（数组）的应用程序很难获得完整的结果。然而，使用有效分解的通信和同步抽象的传统应用程序会产生良好的性能，从而为在云的灵活资源上轻松扩展提供了可能性我们的贡献是：1. 性能研究和访问透明性可行性的评估，通过比较4个未修改的应用程序（进化策略，邻近策略优化，Scikit-Learn网格搜索和Pandas数据帧）在单个VM上和无服务器功能上的执行，以分析加速，并行性和开销。2. 我们概述了这项研究的关键见解：（i）与VM相比，运行和扩展未修改的Python多处理应用程序是可能的，并且性能略有下降，（ii）现有的无服务器开销部分被在单个VM中观察到的超线程效率低下所掩盖，以及（iii）Python的多处理有状态抽象明显地增强了3. Lithops计算框架的扩展，其中包含一个实现Python多处理器的模块，并允许以透明的方式在无服务器函数中执行远程进程。该项目是开源的，源代码在Git-Hub上公开。2本文提出的开放性问题是：我们能否在云中运行遗留的单机并行应用程序，并使用无服务器资源透明地扩展它们？我们能把云编程为无限多核机器吗？2. 相关工作操作系统级别的透明度。隐藏分布式系统的复杂性是系统领域中反复出现的主题。最近关于分解数据中心（DDC）的工业趋势[5]提倡分布式操作系统透明地利用分解的硬件资源，如处理，内存或存储。无论是在AWS EC2上的VM（虚拟机）中，还是在无服务器AWS Lambda上的函数，以比较执行时间，2https://github.com/lithops-cloud/lithops。A. Arjona，G. Finol和PG 洛佩斯未来一代计算机系统140（2023）436438例如，LegoOS [13]是一个分布式操作系统，它实现了Linux系统调用接口的一个子集，以便现有的未修改的Linux应用程序可以在其上运行。LegoOS展示了两个未修改的应用程序如何以分布式方式运行：Phoenix（MapReduce 的单节点多线程实现）和TensorFlow。然而，LegoOS并没有展示可扩展性或涉及可变内存的复杂场景更糟糕的是，在分散的资源上实现整个Linux API是一项艰巨的工程任务。另一种在操作系统层实现访问透明性的方法是GiantVM [14]。GiantVM使用虚拟化在分布式集群上运行未经修改的客户操作系统。 与传统的多对一虚拟化模式（在一台机器上运行多个操作系统）相比，GiantVM实现了一对多虚拟化（在多台机器上运行单个操作系统）。GiantVM使用基础设施即服务（IaaS）在云环境中的集群上运行分布式操作系统。基于当前云技术的方法目前更可行，因为DDC尚未向公众提供在[6]中，作者提出通过将分解的资源显式地暴露给应用程序来增强操作系统的分解，从而在应用程序和远程资源之间应用程序级别的透明度。除了在操作系统级别，透明度也可以在应用程序级别轻松实现。如果应用程序用来访问本地资源的接口被另一个访问分解资源的实现替换或包装，那么我们就可以透明地以分布式方式运行未经修改的本地代码。无服务器社区的早期努力提出FaaSification作为将现有代码移动到无服务器函数的自动化过程[15]。虽然这只意味着简单的功能代码，而不是整个应用程序。Fiber [16]是一个实现Python的多进程API的库，用于在分布式Kubernetes集群中运行远程进程。在他们的文章中，他们执行了几个有状态的AI应用程序，这些应用程序使用Python的多处理库编程为本地并行执行。通过使用Fiber替换多处理，这些未修改的应用程序可以透明地扩展和利用分布式Kubernetes集群上的并行性。虽然我们的工作与Fiber密切相关，但他们将Fiber与其他分布式计算框架进行了比较，而我们希望专注于研究访问透明性，并利用FaaS的高可扩展性找到本地和分布式执行之间的差异。此外，Fiber并没有实现所有的Python多处理抽象（例如，它错过了Lock）。另一个应用程序级别的透明性示例是关键[17]。Crucial是一个实现Java线程接口的库，它允许线程作为无服务器函数透明地使用无服务器，由于FaaS固有的弹性，Crucial大大提高了可扩展性。Crucial还提供了基于分布式共享对象 的 有 状 态 抽 象 ， 这 些 对 象 驻 留 在 一 个 分 散 的 内 存 层（Infinispan）中。然而，Crucial并没有为Java应用程序提供透明性Kappa [18]是一个无服务器计算框架，专注于通过检查点机制和延续函数为有状态的无服务器应用程序提供容错。与我们的工作相反，他们并不强调其贡献的访问透明度。然而，他们声称他们的框架只需要对原始代码进行最小的修改，因为Kappa自动创建检查点。但是，需要一个特殊的API来调用任务（spawn和spawn_map）并在函数之间传递我们相信，这将是有趣的研究容错访问透明性与Kappa框架在未来的工作。我们与相关工作的不同之处在于，我们是第一个评估无服务器分解资源拦截多处理并行库的完全透明性的工作。3. 为Python多处理本节描述了我们如何通过Python多处理库的重新实现来实现对无服务器和分散资源的访问透明性。 图 2描述了体系结构的总体概述。我们利用Lithops框架[12]在分散的无服务器函数上执行并行本地应用程序。Lithops使本地串行代码的执行能够在大规模并行的无服务器函数上运行。Lithops充当抽象层，简化了对公共云中存在的主要FaaS服务的利用，以执行高度并行的任务。Lithops的设计原则之一是确保云之间的可移植性。相同的应用程序可以从一个云提供商无缝移植到另一个云提供商，这可以防止供应商锁定。我们用一个多处理模块扩展了Lithops，它完全实现了原始的Python多处理接口。计算抽象（如Process和Pool）使用Lithops FunctionExecutorAPI。进程间通信（IPC）和同步抽象（如锁和队列）使用Redis内存中的键值数据库实现3.1. 分解计算资源3.1.1. Lithops工作流程Lithops遵循主/工作者架构，其中本地进程充当工作者的协调器和协调器，这些工作者作为无服务器功能在FaaS后端中部署和执行。图1是Lithops的一般操作示意图。3.第三章。首先，用户与Lithops多处理API交互，这是Lithops框架API的包装器（1）。Lithops自动检测，序列化并上传到存储过程接下来，Lithops编排器针对FaaS后端调用相应数量的无服务器功能（ 3） 。例 如， 每个进程 对应 于一个单 一的功能 。Lithopsworker（4）是一个通用的无服务器函数，用于处理Lithops作业任务的执行。它从存储中下载先前上传的代码、数据和依赖项，并在处理错误的包装器中执行用户当任务完成时，结果被上传回存储器。Lithops orchestrator通过拉取存储器的内容来完成任务（5）-当列出结果键时，任务已经完成。最后，下载结果并返回到父应用程序。3.1.2. 无服务器作业队列为非常细粒度和短期运行的任务分叉许多本地进程因此，Python多处理实现了池抽象。Pool表示在池实例化时分叉的一组固定大小的进程。它有类似starmap（）、apply_tagc（）或map_tagc（）的方法，它们允许以更高A. Arjona，G. Finol和PG 洛佩斯未来一代计算机系统140（2023）436439图三. Lithops操作工作流程。图二. 架构图。函数在任务生成时从队列中拾取并执行任务一旦池被关闭（terminate（）），就会向worker发送一条消息来终止它们的执行。这种实现的主要优点是将一组任务提交到Redis列表的开销比为每个任务调用一个函数要低得多使用Redis，我们可以使用一个LPUSH命令一次性提交所有任务，而调用函数是顺序的，开销取决于每个FaaS服务的API此外，重用函数来执行多个任务可以避免冷调用导致的掉队。但是，主要缺点是函数执行时间限制。虽然时间限制多年来一直在增加（例如，AWS Lambda现在支持最长15分钟的调用[19]），但该限制阻止运行更长的执行。3.2. 非聚合内存资源我们选择Redis是因为它的部署简单、内存存储和高性能。Redis与其他传统的键值数据库的不同之处在于，值有一个类型，如LIST，STRING，HASHSET等。这些数据类型上可用的不同操作有助于实现Python的多处理库中存在的一些通信和同步抽象。单节点Redis部署保证了一致性和正确的读写顺序，因为Redis是单线程的，数据备份在磁盘中以进行重启恢复，但不提供节点容错无服务器函数是不可寻址的，并且缺乏从另一个函数打开连接的能力。为了规避这一限制，许多作品已经探索了通过驻留在VM中的可寻址外部代理使用TCP连接[9，20]，或者使用级别，而不是手动创建和管理过程实例。在进程池中，每个操作（map、apply_apply_tagc. . .）创建一个或多个作业，这些作业排队到作业队列中。工作进程从队列中获取并执行作业。这避免了为每个任务创建新进程的需要，从而大大减少了fork开销。此外，初始化全局工作范围变量也很有用，因为它们只需要在创建工作进程时初始化一次。我们已经实现了Lithops多处理池的作业队列模式。在Lithops.multiprocessing.Pool中，worker是在创建Pool对象时调用的长期函数。对池的操作（map（），apply（））会生成Lithops任务，但不是调用新函数来执行这些任务，而是在Redis列表中排队工人NAT打孔技术打破FaaS网络，并在功能之间实现类似P2P的连接[21]。然而，所有这些方法仍然需要外部会合服务器，但最重要的是，它们不支持集体通信。许多多处理抽象需要同步的和原子的AC。cess，例如将一个项目排队到队列或发出释放锁的信号，Redis单线程实现以安全但快速的方式满足了这一要求。在Python的多处理中父进程创建所有资源，然后在子进程分叉时传递一个引用给子进程使用Lithops，传递给函数的对象和引用必须是可序列化的。为了保持相同的行为，我们遵循了一种模式，其中每个资源对象（队列，A. Arjona，G. Finol和PG 洛佩斯未来一代计算机系统140（2023）436440−烟斗......）在Redis中充当键值对的代理，是国家的所在地每个对象都是唯一标识的，并对应于特定的Redis键值对。每个代理资源实现垃圾收集的引用计数。计数器始终存储在Redis中，当引用为零时，资源将从Redis中删除。此外，每个资源默认包含一个小时的密钥过期时间它被用作备份，以防代码中出现错误，程序突然终止，因为引用计数机制可能不会以优雅的方式删除资源。下面列出了可用的不同抽象以及它们如何实现消息传递：管道用于一对进程之间的双工通信。一个新的Pipe返回一个包含两个Connection对象的元组，每个对象对应一个Redis LIST。可以使用Connect-ion.send（）将数据写入管道的一端，并可以在另一端使用Connection.recv（）读取数据。send（）方法执行LPUSH命令将数据放在列表的尾部，recv（）方法执行BLPOP命令从头部列表获取数据这样，列表就被视为FIFO队列。BLPOP获取并删除列表的头项，或者阻塞直到有可用的元素对象的实现方式与管道相同，不同之处在于可以有两个以上的进程从对象中放入或移除项。一个队列。Redis维护puts的顺序并保持一致。共享状态：数组和值用于在Python多处理中共享内存。只能将基本的C类型值放入数组或值中。它们是使用LIST类型实现的。进程可以读取和写入数组的特定索引或切片。一个值是一个大小为1的数组。我们选择使用LIST类型而不是STRING，因为STRING值的大小限制为512 MB，而在列表中，列表中的每个元素的大小最多为sizeof（长双精度型），列表最多可以容纳2321个元素。管理器允许在一个单独的进程中创建Python资源，并通过套接字访问它们。管理器用于与多个进程共享基本的Python数据类型，例如dict或list。使用Redis实现这些类型是很简单的，因为它本身就提供了HASHSET和LIST类型管理器还允许创建用户定义的类，驻留在Manager和其他进程中实例化使用远程方法调用来访问它。为了使用Redis提供类似的行为，我们让每个进程都有Manager类的本地实例，但是用户定义的类实例的状态（即其属性）作为简单的键值对远程存储在Redis中。锁确保一次只能由一个进程同步：信号量和锁使用LIST类型实现。当创建信号量时，将N个令牌添加到列表中，N 是信号量的初始值信号量的每个acquire（）都将执行一个BLPOP命令，该命令从列表中删除一个令牌。release（）方法使用LPUSH命令将令牌放回列表如果在调用acquire（）时没有令牌（意味着N个进程当前处于临界区），BLPOP命令将阻塞，直到其他进程执行release（）并放回一个令牌到列表中。请注意，在这个实现中，信号量的值将始终大于零。锁是信号量的一种推广，其中N为1。为了实现条件，使用多个通知列表来通知等待条件事件的阻塞进程当一个进程达到条件并挂起wait（）方法时，3.3. 分散的存储资源Lithopsmultiprocessing 还 实 现 了Python内置的open函数和os.path模块的副本，允许透明地读取和写入存储在分散存储服务（如S3）上的文件和目录，就像它是本地文件系统一样。这对于FaaS特别有用，因为函数容器中挂载的卷是易失性的，并且当执行完成时，存储在那里的数据通过这种方式，我们为无服务器进程提供了一种透明的方式来保存或恢复它们的状态。然而，应该注意的是，由于我们正在处理不可变的数据，因此不可能像在传统网络文件系统中那样修改或扩展文件而不必重写整个文件，这对于大文件来说可能是有问题的。但是，如第5.4节所示，分散存储服务提供了更高的并行读写吞吐量而不是传统的单片计算机中使用的磁盘。需要并行读取大量数据的应用程序（例如，视频编码）可以从分散存储中受益，从而降低执行时间。4. 评估设置本节旨在描述已经进行下述实验的配置除非另有说明，否则实验已在以下设置下运行：Lithopsorchestrator在带有Ubuntu 20.04的m5.2xlarge EC2主机上运行，Lambda使用容器化Python3.8运行时，1769 MB RAM3作为无服务器功能，Redis 6.2实例在宿主机上运行Docker。主机和AWS Lambda位于同一个VPC私有子网、区域和可用区（us-east-1 A），因此流量不会通过NAT网关或公共互联网。在使用S3作为存储后端的情况下（将被说明），S3桶位于相同的区域中，并且通过私有端点完成对S3的访问。所有的Lambda函数都是使用温容器执行的。所有本地单片执行都是使用具有不同数量vCPU的按需AWSEC2实例执行的具体来说，我们使用了以下实例：带有16个vCPU的c5.4xlarge、带有32个vCPU的c5.9xlarge、带有64个vCPU的c5.18xlarge和带有96个vCPU的c5.24xlarge。所有这些c5 EC2实例都运行Ubuntu 20.04，并且位于us-east-1区域。请注意，本地执行的共享内存抽象使用本地内存，而远程无服务器进程使用Redis。由于我们想要研究访问透明性，因此用于两种配置的代码完全相同，只是我们更改了import语句，以便无服务器执行使用远程有状态抽象（从import multiprocessing到im）。端口lithops.多处理）。在其他文字，所有本地使用单个虚拟机的执行使用标准Python多处理库和本地资源（进程，共享内存），而无服务器执行则使用Lithops多处理库和远程资源（无服务器函数，Redis）。我们放弃在内部环境中执行执行有两个主要原因。首先，我们无法使用物理资源来模拟云环境，因为我们不确定EC2中使用的硬件，而且云多租户资源共享。其次，AWS Lambda运行在EC2类型的实例上，因此将本地本地执行与Lambda进行比较是不公平的。不同验证的源代码是开源的，并在GitHub上公开提供。4该过程将新列表注册到通知列表集合，用一个BLPOP命令将块指向它 满足条件的进程将向通知列表集的每个列表添加一个元素，以便所有等待的进程都被解除阻塞，并恢复执行。障碍和事件是条件的具体情况。3 根据AWS文档[19]，一个1769 MB内存的运行时被分配了一个完整的vCPU，作为一个vCPU，一个具有超线程的CPU线程[22]。4 https://github.com/aitorarjona/lithops-transparency-validation上下载。A. Arjona，G. Finol和PG 洛佩斯未来一代计算机系统140（2023）436441≈≈表1分解产生的间接费用。这些值表示地图作业的所有功能相调用类型冷温暖序列化数据和函数0.004秒0.004秒上传依赖项0.002秒0.001秒调用1.719秒0.258秒功能设置0.052秒0.046秒加入0.628秒0.630秒总2.407秒0.939秒表2分解产生的间接费用。这些值表示地图作业的所有功能有效载荷大小远程（Redis）当地1 KB0.6 ms0.0463毫秒1 MB23.4毫秒2.56毫秒100 MB1.12秒0.288秒见图4。 处理池调用结果。5. 微观基准评价本节的目的是执行微基准测试，使我们能够识别潜在的开销以及它们在哪里产生，这将有助于我们了解实际应用程序的验证结果。5.1. 分叉连接开销并行计算的主要开销之一是创建新线程或进程的成本。本实验的目的是测量调用多个并行无服务器进程时产生的开销，并分析当函数数量增加时它们如何扩展。Lithops允许使用不同的存储后端和监控系统来实现无服务器功能。在这个实验中，我们将比较使用S3或Redis作为存储后端和任务监控的性能。该实验包括执行多处理池几个睡眠函数的映射，每个睡眠函数将睡眠5秒。图 4表示不同并行执行的总开销。开销时间的计算方法是从总执行时间中减去休眠时间。对于低并行度，Redis和S3同步都提供1 s的开销。从32个进程开始，Redis可以提供比S3更低的开销：在1024个函数中，Redis同步的开销比S3低1秒。我们还测量了Lithops和AWS Lambda调用在何处产生这些开销。图5表示使用Redis作为存储后端的1024个并行函数的5个睡眠秒的映射作业的分解。左图所示的执行使用冷容器，而右图所示的执行使用热容器。我们可以看到函数启动开销的差异。当使用冷容器时，开销更高，因为提供者必须分配资源来运行函数，而当使用热容器时，资源已经分配并且容器已经启动并运行，因此开销要低得多。具体来说，温调用通常具有大约200 ms的开销，而冷调用可以具有更多的变量和更高的开销。在这种情况下，冷调用的开销超过秒，获得的平均开销为1.7秒。我们也可以看到执行的开始不是瞬时的，而是线性的。 这是因为使用Python线程的异步调用是顺序执行的。这意味着，函数的调用开销越大这也意味着不能立即实现完全并行。需要精确并行执行的应用程序应该使用某种同步机制（例如屏障）。表1显示了Lithops和AWS Lambda引入的开销分解。这些值表示同一映射作业的所有功能的平均时间。我们已经用冷热容器执行了两次死刑 这些值是恒定的，因为两者使用相同的数据和存储后端。'我们可以看到，由于上述原因，使用冷容器执行死刑的时间更长。'都被微影协调器检测到了最后，所有间接费用的总和显示在"总计"行中开销时间决定了流程任务的最小粒度。运行时间低于开销的短期运行任务将不会从分布式无服务器执行中受益。此外，粒度越接近开销时间，其相对于总应用程序执行时间将越显著。5.2. 网络等待时间和吞吐量访问透明性的主要限制和瓶颈将是对远程共享有状态资源的访问延迟。通过这些实验，我们希望确定使用Redis的共享内存的限制以及远程进程之间的网络延迟和带宽。首先，我们将确定并比较本地（VM）和远程（无服务器函数）通信的延迟。我们通过多处理管道发送可变大小的有效载荷，并测量往返时间。 本地管道是UNIX管道，Lithops MultiprocessingPipe使用Redis列表。延迟结果在表2中列出。我们看到远程通信的延迟使用Redis的通信比本地通信高一个数量级，因此性能无法比较。然而，我们注意到，对于小的有效负载（小于1 KB），延迟低至毫秒，这使得不需要数据传递的同步操作（如锁或信号量）的开销较小。A. Arjona，G. Finol和PG 洛佩斯未来一代计算机系统140（2023）436442≈图五、sleep（5）map作业的函数阶段分解。（一）冷召（二）暖召。见图6。 公布结果。其次，我们想测量由Redis支持的Lithops多处理管道的最大吞吐量。我们通过一个管道发送1000条大小为1MB的消息（总共1GB），以通信两个运行在无服务器函数中的远程进程。我们可以在图中看到。图6显示，发送消息所经过的时间稳定在15 ms，尽管我们可以观察到一些异常值，这可能是由共享网络使用干扰引起的。总传输时间为10.5 s，因此有效吞吐率为90 MB/s。从这个结果中，我们可以确定远程进程之间的传输数据时间，这将表明是否值得为某些工作负载使用分散的资源。5.3. 计算性能本实验的目标是在一个并行示例中测量计算性能，并使用Lithops比较大型VM和无服务器函数之间的执行时间和可扩展性。我们使用经典的例子计算圆周率的蒙特卡罗方法进行实验。特别地，该测试基于对3，200，000，000个随机点进行采样，并计算单位圆内的点的数量以提取Pi数的近似值要采样的点的数量图的结果。7表明，使用FaaS的Lithops可以获得的可扩展性能力远远超过一台机器可以实现的，尽管执行的代码是完全相同的。单个进程的基线执行时间为1254.8 s。对于16个过程，我们观察到，与单片系统相比，分散系统的性能优越20%至25%。这是因为，在在虚拟机中，由于使用了超线程技术，进程之间共享物理CPU内核，但尽管如此，浮点运算的数量仍然受到所使用的物理CPU内核的限制。相反，函数不存在此限制，因为AWS Lambda使用的物理节点禁用了超线程[23]。然而，如果我们坚持文档，对于1769 MB的内存，函数被分配一个vCPU [19]，即一个CPU线程[22]。如果我们参考官方文档，我们可以得出结论，在vCPU数量相等的情况下，函数比VM具有我们还可以观察到，对于96个进程，即VM上限，分解和单片系统收敛并呈现大致相同的性能。这是因为虚拟机中存在的超线程效率低下掩盖了Lithops开销（参见第5.1节）5.4. 磁盘性能本实验的目的是测量在FaaS上运行的Lithops进程的磁盘读写能力和可伸缩性该实验有两个阶段：在第一阶段，的进程将向磁盘写入1 GB文件在第二阶段，A. Arjona，G. Finol和PG 洛佩斯未来一代计算机系统140（2023）436443见图7。 蒙特卡罗算法结果表3不同数组大小的不同并行快速排序实现的执行时间。阵列大小5 M10米战略当地石龙属当地石龙属共享阵列带有本地副本的共享数组消息传递23.66秒15.693秒十四点二十七秒–356.60秒十七点半79.68秒47.11秒45.16秒––45.63秒图8.第八条。 磁盘读写速率。另一批进程从磁盘读取在第一阶段写入的数据。该实验是针对不同数量的进程来研究可扩展性的，我们测量聚合的读写速率。使用的存储后端是S3。结果，如图所示。8，显示出高可扩展性和聚合带宽，读取峰值为80 GB/s，写入峰值为65 GB/s。与通用SSD（gp2）EBS卷相比其最大吞吐量为250 MiB/s5 [24]，与安装在VM上的单个卷相比，分散存储的写/读吞吐量高得多。 这对于需要从存储中并行读取大量数据的应用程序可能很有用，因为使用FaaS我们可以实现更高的吞吐量，从而降低执行时间。5.5. 共享内存性能我们还想验证使用远程共享内存时的性能损失。在这个实验中，我们使用共享内存实现了一个并行排序算法，并比较了本地和无服务器执行。排序算法包括将数组拆分成块，并行地对每个块执行快速排序，然后递归地合并5 对于大于334 GB的卷，不考虑突发信用。按照树模式排序的块。该算法大量使用数组，因为它会迭代多次，并且列表项不断改变位置。我们遵循三种策略来实现该算法。第一种使用多处理虽然数组存储在共享内存中，但每个进程只访问其对应的块，因此不需要提供互斥和临界区。第二种策略也使用共享的多处理数组，但每个进程都将其块复制到一个局部变量，执行操作然后将该切片复制回共享内存阵列。第三种策略不使用共享数组，而是使用管道和消息传递。父进程使用管道将块发送到每个工作进程，工作进程执行树合并阶段，也使用它们之间的管道传递它们的块。我们已经实现了这三种策略，以表明，尽管这三种策略都适用于本地执行，但在使用分解内存时，访问内存的方式表3显示了使用64个进程在本地和无服务器上使用不同数组大小（5 M和10 M）的三种替代实现的执行时间。对于本地执行，我们使用了具有64个vCPU的 c5 EC2实例我们可以看到，Lithops无法使用就地共享数组实现来执行算法。这是因为每次访问列表索引都相当于一个Redis命令请求。这导致了禁止性的开销，阻止使用这种共享内存方法获得本地复制实现是一个低工作量的改进，在地方共享阵列实现。尽管如此，由于高数据复制开销，Lithops难以执行。最后，提出了利用Pipes进行消息传递的方法来使用分解存储器实现该算法。由于不再使用共享内存，Lithops现在能够A. Arjona，G. Finol和PG 洛佩斯未来一代计算机系统140（2023）436444···表4每个应用程序使用的算法类型和有状态抽象的摘要。应用程序算法类型共享消息平行状态传递地图进化策略迭代池映射Pandaral lelScatter-Gather分散-聚 集 网 格 搜 索广播-聚集公司简介与当地执行相比，提供了胜任的业绩。对于10 M数组大小的执行，我们可以看到，而无服务器执行导致相同的执行时间。我们还可以看到，与共享内存的替代方案。这告诉我们，即使我们有快速访问的本地共享内存，它有时也不是最好的选择，即使在本地执行中。5.6. 微观基准结论正如我们在不同的实验中所看到的，主要由网络延迟产生的开销是非常值得考虑的。我们获得的开销高出几个数量级（本地微秒与远程毫秒相比）。然而，整体性能并没有受到严重影响，因为超线程惩罚掩盖了网络产生的开销。使用AWS Lambda等FaaS为我们提供了出色的即时可扩展性，尽管额外的开销更为显著。例如，由于函数之间缺乏直接通信，因此必须通过分解的内存组件使用间接通信。 在这方面，我们正在评估非最佳场景中的透明度-更好的替代方案是使用多个VM，其中我们将受益于直接通信，或者我们可以避免函数调用开销（已经并置的远程进程）。另一方面，我们将失去快速和动态扩展的能力。确切地说，当透明地运行使用多处理的Python脚本时，这些属性至关重要。直到程序运行时，我们通常无法提前知道进程的数量或者我们将使用哪些共享状态通信抽象或者进程的数量在整个程序执行过程中是否变化。如果我们要使用虚拟机集群，则总容量将是固定的，因此有时会发生过度配置（部署的资源比我们实际需要的多）或配置不足（由于负载更大而限制6. 应用在本节中，我们将评估Lithops在四个不同实际用例中的行为，以测试访问透明度并衡量性能。使用的场景是：在其基线存储库中实现OpenAI的邻近策略优化（PPO）算法，Uber研究团队在Evolution Strategies中进行的POET修改，使用Pandarallel 进 行 的 并 行 Pandas 框 架 转 换 ， 以 及 使 用 Scikit-learn 的Gridsearch在Joblib上运行的超参数调优。为了使这些应用程序适应无服务器，我们只需要取代的 多重处理输入关于Lithopsltiprocessing。由于Lithops完全实现了多功能，cessing接口，其余的代码不需要任何进一步的改性表4描述了应用程序和其中使用的算法类型。我们还指定了什么样的有状态抽象被使用。在每一节中，我们将详细介绍每种算法如何处理共享状态和消息传递。我们已经从Fiber [16]验证中获取了PPO和Evolution Strategies应用程序，因为它们是使用多处理库的真实而复杂的应用程序。然而，我们认为与纤维的比较是不公平的，因为(i)Kubernetes和AWS Lambda中的容器创建时间不具有可比性，（ii）Fiber