Page 102 - 《软件学报》2025年第5期
P. 102

2002                                                       软件学报  2025  年第  36  卷第  5  期


                 平台的服务节点在物理位置上无法保证位于同一个区域, 从而影响性能度量的公平性. 这一局限性是不可避免的,
                 是因为每个服务器无感知平台都有其专门的服务器集群和服务位置. 因此, 各个平台即使在相同服务位置上, 其节
                 点服务的物理区域可能也存在差异. 为了确保我们对                 4  个平台性能比较具有公平性和有效性, 我们在选择节点服
                 务位置时确保了它们在更高粒度的服务区域上保持一致, 比如                     us-east-1, 以最大程度地减少实验测试机器到服务
                 节点之间的网络开销影响. 在本文研究中, 我们着重保持了服务位置的一致性, 以尽量减少因物理位置差异而引起
                 的性能差异.
                    (3) CPU  密集型任务的线程: 在我们微基准测试程序中包含              CPU  密集型任务. CPU   密集型任务可以使用多线
                 程发挥平台的     CPU  潜力. 然而, 在我们实验场下, 我们对该任务没有使用多线程. 原因在于, 本文第                    3  节的特征分
                 析揭示, 大多数服务器无感知平台根据配置的内存量按比例分配                      CPU  处理能力. 例如, 亚马逊    Lambda 在内存大
                 小约为   1 769 MB  时得到一个  vCPU  的处理能力, 而谷歌     Cloud Functions 和阿里巴巴  Function Compute 分别在内
                 存大小约为    2 048 MB  和  1 024 MB  时得到一个  vCPU  的处理能力. 在这种情况下, 即使     CPU  密集型任务使用多线
                 程, 平台也限制了     CPU  处理能力的分配. 因此, 在我们性能实验中探究的内存下, 不能保证各个平台都支持多线程
                 行为. 基于此, 为了保证平台之间比较的公平性, 我们的              CPU  密集型任务关注于单线程的科学计算任务.
                    (4) 内存密集型任务的特征: 在我们微基准测试程序中包含内存密集型任务, 该任务完成斐波那契数列计算.
                 在资源方面, 该任务能从内存带宽和内存容量上充分撑满任意大小的资源. 因为该任务的计算时间是根据要计算
                 的数列元素下标而定. 一般来说, 当求解的数列元素下标大时, 在进行内存读取和写入操作需要的内存带宽就高,
                 中间结果存储以及内存交换需要的内存容量也大. 在栈方面, 当栈过深时, 可能会发生栈溢出. 因为该任务使用递
                 归的方式来实现. 每一个递归调用都会将一些数据压入栈中, 如果栈深度过深, 可能会导致栈溢出, 但最终还是受
                 服务器无感知平台底层提供的函数实例的硬件限制. 为了防止在我们实验过程出现内存带宽和内存容量不够或栈
                 溢出的情况, 我们不使用可能造成这些问题的大的输入数列元素来比较                       4  个平台的执行性能.

                 7   总 结

                    在本文中, 我们对亚马逊         Lambda、谷歌    Cloud Functions、微软  Azure Functions  和阿里巴巴  Function
                 Compute 这  4  个主流的公有云服务器无感知平台进行了全面可靠的度量研究. 通过特征总结和运行时性能分析,
                 本文深入研究了这些平台. 在特征总结部分, 本文更新并分析了平台官方文档中描述的开发、部署和运行时的关
                 键特征. 我们发现不同平台在这些特征方面存在差异. 例如, 亚马逊                    Lambda、谷歌   Cloud Functions 和阿里巴巴
                 Function Compute 采用基于分配的内存使用量的付费模型, 而微软            Azure Functions 则是基于消耗的内存使用量计
                 费. 我们还发现了实践中的配置和文档之间存在不一致的现象, 例如亚马逊                      Lambda 实际上无法配置超过       3 008 MB
                 大小的内存. 在运行时性能分析部分, 本文从两个性能角度对平台进行了研究, 即冷启动性能和执行性能. 在冷启
                 动性能中, 本文研究不同编程语言和不同内存大小对平台的影响; 在执行性能中, 本文研究不同任务类型对平台执
                 行性能的影响. 结果表明, 不同的平台对不同语言的冷启动性能表现不一致. 例如, 亚马逊                          Lambda 和谷歌   Cloud
                 Functions 执行  Python  应用和  JavaScript 应用比执行  Java 应用获得的冷启动开销更小. 不同平台对不同类型任务
                 的执行能力也存在差异. 例如, 在考虑复杂任务的执行速度时, 基于内存消耗的微软                        Azure Functions 提供最快的执
                 行性能. 但对于其他      3  个基于内存分配的平台, 阿里巴巴         Function Compute 可为复杂任务提供更快的执行效率. 基
                 于分析结果, 我们提供了一系列对开发者和云计算厂商具有实际指导意义的启示, 并为研究者提供了潜在的研究
                 机会.


                 References:
                  [1]  Fouladi S, Wahby RS, Shacklett B, Balasubramaniam KV, Zeng W, Bhalerao R, Sivaraman A, Porter G, Winstein K. Encoding, fast and
                     slow: Low-latency video processing using thousands of tiny threads. In: Proc. of the 14th USENIX Symp. on Networked Systems Design
                     and Implementation. Boston: USENIX Association, 2017. 363–376.
                  [2]  Ao LX, Izhikevich L, Voelker GM, Porter G. Sprocket: A serverless video processing framework. In: Proc. of the 2018 ACM Symp. on
                     Cloud Computing. Carlsbad: ACM, 2018. 263–274. [doi: 10.1145/3267809.3267815]
   97   98   99   100   101   102   103   104   105   106   107