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

温金凤 等: 服务器无感知平台性能度量研究                                                           1999


                 成本. 因此, 在设计应用时, 开发者需要综合考虑延迟和成本因素, 权衡使用云存储服务的利弊.
                    (5) 改进不同编程语言的冷启动机制: 根据第            4.1  节中关于平台内的冷启动延迟结果比较, 可以看出每个平台
                 在不同编程语言应用的冷启动延迟方面存在差异. 例如, 亚马逊                    Lambda 在执行  Python  和  JavaScript 应用时的冷
                 启动延迟要低于执行        Java 应用的延迟, 几乎快了将近两倍. 而微软          Azure Functions 在执行  Java 应用时产生更低
                 的冷启动延迟, 低于近       700 ms. 这表明每个平台对不同编程语言应用的启动机制和处理能力可能存在差异. 基于
                 我们的结果, 各云计算厂商应该重视平台在这一问题上的表现, 并致力于改进冷启动机制. 一个理想的服务器无感
                 知平台应该具备低冷启动延迟且在不同语言之间延迟差异不大. 开发者期待能够使用这样的平台, 无论是在
                 Python、JavaScript 还是  Java 等多种编程语言下, 都能获得类似的冷启动性能. 为了改进冷启动机制, 云计算厂商
                 可以采取一系列措施. 首先, 他们可以优化服务器启动过程, 减少启动时间和资源消耗. 其次, 他们可以针对不同编
                 程语言的特点, 针对性优化运行时环境和加载机制, 以提高冷启动效率. 此外, 他们还可以探索智能预热技术, 提前
                 根据行为模式或预测需求进行函数的预加载, 以减少冷启动延迟. 这些改进措施将有助于提升平台的性能和用户
                 体验. 总之, 改进不同编程语言的冷启动机制是云计算厂商的重要任务. 他们应该持续关注每个平台在这方面的表
                 现, 并积极改进平台启动机制, 以满足开发者对低延迟且延迟差异不大的服务器无感知平台的期望.
                    (6) 选择提供低冷启动延迟的平台: 根据第            4.1  节中关于平台间的冷启动延迟结果比较, 可以得出结论: 在不
                 同服务器无感知平台下, 3       类主流编程语言应用的表现相似, 即亚马逊              Lambda 和阿里巴巴    Function Compute 在执
                 行  Python  应用、JavaScript 应用和  Java  应用时, 其冷启动延迟都明显低于谷歌         Cloud Functions 和微软  Azure
                 Functions. 这意味着开发者可以有针对性地选择提供低冷启动延迟的平台来执行应用, 从而提高整体的用户体验.
                 通过选择具有较低冷启动延迟的平台, 开发者可以减少用户等待时间, 提高应用响应速度, 并增强用户对应用的满
                 意度. 此外, 较低的冷启动延迟还能对应用的可伸缩性和弹性产生积极影响. 在面对突发的高并发流量或需要频繁
                 启动新实例的场景下, 低冷启动延迟的平台能够更快速地响应需求, 确保应用的可用性和性能稳定性.
                    (7) 选择执行性能最优的平台: 1) 根据第         4.2  节的研究结果, 在基于内存消耗的微软          Azure Functions 上任何任
                 务都可以获得最快的执行性能和最低的成本. 然而, 微软                 Azure Functions 的缺点是开发者失去了对内存分配的控
                 制权. 相比之下, 对于其他      3  个基于内存分配的平台, 阿里巴巴         Function Compute 能够提供更快的执行效率和更低
                 的成本, 该平台在执行性能和成本之间提供了不错的平衡, 具有广阔的应用前景. 2) 不同任务类型对不同平台的执
                 行性能稳定性产生影响. 例如, 亚马逊           Lambda 在图片处理任务上执行稳定, 但对于图计算任务表现不佳. 对于机
                 器学习训练和推理任务, 亚马逊          Lambda 和阿里巴巴    Function Compute 表现较好. 因此, 选择执行性能最优的平台
                 需要考虑特定任务的性质. 3) 我们比较了           4  个平台在执行同一任务的成本. 在保持平台内存大小一致的情况下, 任
                 务成本取决于各平台执行该任务的执行时间. 我们观察到不同平台的计费单价相差不大, 因此, 成本取决于执行任
                 务所需的时间. 短时间内完成任务的平台通常让开发者花费更低的成本, 因此, 选择执行性能最优的平台也涉及成
                 本效益的考量. 选择执行性能最优的平台并非固定不变的选择, 而是一项需要动态权衡特定需求、任务性质和成
                 本效益的决策过程. 随着云计算领域的不断演进, 开发者应该根据任务要求和性能目标灵活选择服务器无感知平
                 台, 以最大程度地满足其需求.

                 5.2   研究机会
                    (1) 分解长时应用为短时函数: 服务器无感知平台存在着函数执行时间限制, 如亚马逊                        Lambda 最多执行  15 min
                 函数, 这表明服务器无感知计算的架构设计主要适用于短时任务. 然而, 若帮助开发者实现长时应用的执行, 研究
                 者可以从以下几个方面展开研究. 一种方法是通过对运行时执行进行分析, 将长时间任务的功能分解为多个短时
                 的子任务函数, 可以确保每个子任务在允许的函数执行时间内完成, 并避免引起执行失败. 这样, 每个子任务可以
                 在独立的函数中执行, 通过事件驱动机制或异步调用的方式进行协调和串联. 举例来说, 我们宏基准测试程序中包
                 含一个图片处理任务, 该任务对待处理图片进行翻转、旋转、过滤、调色和缩略图等多种操作. 逐个处理完所有
                 操作可能需要执行很长时间. 基于此, 将该任务的多个图像处理操作转化为多个短时函数可能是一个有效性的优
                 化策略. 具体来说, 每个图像处理操作           (如翻转、旋转、过滤、调色和缩略图等) 可以作为一个独立的函数, 这样
   94   95   96   97   98   99   100   101   102   103   104