函数性能探测：更简单高效的 Serverless 规格选型方案

作者：拂衣、丛霄

2019 年 Berkeley 预测 Serverless 将取代 Serverful 计算成为云计算新范式。Serverless 为应用开发提供了一种全新系统架构。借助 2023 年由 OpenAI 所带来的 AIGC 风潮，以阿里云函数计算 FC、AWS Lambda 为代表的 Serverless 以其更高成本效益、更简化的后端代码 & 扩展性及更极致的弹性等众多特性，将开发者从繁重的手动资源管理与性能成本优化中解放，再次激发开发者蓬勃的想象力与创造力。国内越来越多开发者及企业开始尝试如何将 Serverless 应用于实际业务或者场景。

但在优雅使用 Serverless 之前，依旧有不少小问题需要提前解决。由于 Serverless 平台的扩缩容是基于请求处理/事件驱动的并发度进行扩缩容的，对于习惯基于 CPU 指标进行 Pod 水平扩缩的的开发者而言，就会遇到以下难题，比如并发度、最小实例数、最大实例数这几个参数之间的关系是什么样的？又比如单个实例最大并发度怎么设置，才能够符合自己的业务需求？

01 Serverless 参数配置的考量维度

Serverless 能提供一定通用能力，但针对不同业务逻辑需要采取合适的配置才能更好的发挥 Serverless 价值。但如何评估函数的最佳配置涉及到多变量协同优化的问题，虽然函数计算 FC 提供了基于应用“每日请求总数”和“平均请求响应时间”的请求预估、基于应用目前使用的服务器“规格”和“利用率”的现有服务器用量预估等方式辅助进行参数配置。但想要更好进行配置，我们建议从以下三个维度去评估配置 Serverless 服务参数。

（1）在成本与性能之间进行取舍

如何根据业务偏好选择性能优先或成本优先是参数配置需要考虑的第一大难点。在单实例多并发数相对固定的情况下，可以提高单实例并行处理请求数量，减少实例数，从而降低成本。当并发数过高时会增加资源竞争，导致性能延迟增加，从而增加成本；如果对于延时敏感度相对较低，可以选取较低实例规格，单价成本更低，与之相反，想要更短延时，可以选择较高的实例规格，但单价成更高。

（2）结合不同函数业务逻辑的复杂度

除了成本和性能取舍，针对不同类型函数逻辑，不同配置参数效果也有着巨大差异。很多函数业务逻辑复杂，只针对单一逻辑分支进行特定配置并不代表整体性能最优；不恰当的配置可能产生大量预期之外的运维成本。对此，我们针对 CPU 密集型、 IO 密集型不同类型函数进行测试，以便更好的挖掘不同规格与不同类型函数TPS之间的关系。

• 在不同规格下，对 CPU 密集型函数进行压测

可以看到 CPU 密集型规格越高， maxTPS 越大，规格与 maxTPS 呈现明显线性关系。规格越大，maxRT 越低 ，说明 CPU 密集型的函数，增大资源规格可以显著降低 RT。但规格增大到 4G、8G 后，对 RT 的降低效果边际效应递减。

• 在不同规格下，对 IO 密集型函数进行压测

可以看到规格提升对 IO 密集型的性能改善非常有限，规格与 maxRT、maxTPS 关联度有限。特别扩展到高规格后，对于 maxTPS 的提升较小。

借助上面压测，我们可以看到这样子的结论：对于 CPU 密集型函数，规格增加对单实例性能的提升能够提供较大的改善。但对于 IO 密集型函数，规格增加对单实例性能的提升存在边际递减效应。当超过一定规格后，规格提升对性能提升几乎没有提升。

（3）兼顾函数配置对计算资源配置的影响

由于函数并发度、最小实例数、最大实例数等配置会影响到 Serverless 平台的资源分配，保证单函数资源刚性交付、多函数的资源隔离同时，合理利用平台弹性调度能力并提高资源利用率是最后要考虑的问题。

以同时处理 x 个并发请求场景举例，当实例并发度设置为 1 时，每个实例同时只能处理 1 个请求，函数计算需要创建 x 个实例来处理这 x 个请求。当实例并发度设置为 X10 时，每个实例同时可以处理 X10 个请求，函数计算只需要创建 1 个实例就能处理这 x 个请求。

单实例多并发适用于函数中有较多时间在等待下游服务响应的场景。等待响应一般不消耗资源，在一个实例内并发处理可以节省费用。但较低单实例并发度在函数流量波动变化时会提前达到单实例并发上限，导致实例扩缩容、冷启动更频繁。与此同时，需要创建和维护更多实例个数，造成整体资源利用率偏低。

02 评估参数配置的合理性

结合以上三个维度，我们可以看到评估 Serverless 的参数配置绝非易事。很多用户在开始尝试使用 Serverless 时仅是通过文档指引进行相关参数配置。在函数正式上线后，很快就会发现之前配置不合理，所造成的成本超预期以及性能不及预期等问题，并尝试反复修改函数配置进行验证。资深开发者会选择进行压测，以便测试出最佳的函数配置。但压测脚本配置、压测数据报告解读需要有一定的实践经验，开发者也无法十分笃定压测所得出的配置结论是否是符合业务预期的最优选择。在统计了海量用户实际配置使用情况后，我们发现表示用户实际资源使用量较低，实际配置规格偏大，造成一定的浪费。

为了更好的验证配置参数的合理性，函数计算 FC 提供基于性能测试 PTS 能力的函数性能探测功能来评估函数单个实例在不同规格下的性能上限，借以推荐满足用户预期延迟的最佳并发度与函数规格配置，探测方法基于 little's law [ 1] 排队理论（并发数 = 请求的平均延迟 * TPS ），如图示：

（横坐标是并发数，左边的纵坐标是 TPS，右边的纵坐标是延迟）

由于每个服务器的处理能力都有限，所以会出现随着并发数上升，吞吐量先上升后平缓，可能出现下降，即性能恶化；当并发度过高时，延迟会变高，甚至会急剧恶化。通过性能探测，我们会得到每种规格的关键性能数据，即每个规格最高能承受的 QPS，在知晓自身对业务流量规模前提下，即可得出最恰当的函数所需的最小实例数和最大实例数以最佳规格和规格下的最佳并发度。我们可以只压测单实例，因为在性能表现平稳的系统，多实例的性能是单实例性能的线性叠加，所以只需要压测出单实例的性能，就可以推算出多实例的性能。

比如，用户预期函数调用端到端延迟为 1000 ms，根据 1000 毫秒的延迟限制选型出最佳的规格及该规格下最佳并发度，即满足延迟限制的最高 QPS 的对应并发度。

由于目前性能探测仅支持对 HTTP 函数进行压测，不支持对事件函数进行压测。仅支持单实例压测，不支持多实例压测。因此，我们提供性能探测（单实例）、性能测试 PTS（多实例）两种方式进行验证。

• 关于性能探测

作为函数计算 FC 的功能之一，为了进一步降低行能探测的使用门槛，功能采取流程化指引，同时性能探测功能完全免费， 用户只需要为函数承接的请求流量付费，不需要为压测功能付费。

• 关于性能测试 PTS

作为阿里巴巴集团淘宝双十一的性能测试工具，性能测试 PTS 支持按需发起压测任务，可提供百万并发、千万 TPS 流量发起能力，100% 兼容 JMeter。提供的场景编排、API 调试、流量定制、流量录制等功能，可快速创建业务压测脚本，精准模拟不同量级用户访问业务系统，帮助业务快速提升系统性能和稳定性。目前，提供新用户 5000VUM 的免费试用额度。

03 针对单实例，如何通过性能探测验证单实例配置参数

接下来，我们简单介绍性能探测的配置流程，仅需三步即可快速发起性能探测。

（在执行压测前，请先点击 API 测试，验证 API 的 HTTP 请求参数是否配置正确，函数是否能成功执行。）

说明： 函数计算的压测功能仅支持单实例压测。如您需要配置多实例压测，请单击单实例压测结果分析页签右侧的多实例弹性能力压测，跳转至 PTS 控制台 [3 ] 配置。

但需要特别说明的是，性能探测推荐的函数配置优先保证满足性能需求，实现最高的资源利用率，但真正实现最低成本配置，需要结合函数线上历史流量数据分析，进行推荐。在进行成本优化推荐规格时，不仅需要达到节约成本的目的，还需要保证不破坏现有服务的 QoS，即性能不会因为实例规格的降低，而导致延迟增大。

04 针对多实例，如何借助性能测试 PTS 进行多实例配置参数

接下来，我们简单介绍性能测试 PTS 的配置流程，仅需配置 API，即可快速发起压测。

在创建 PTS 场景页面，设置场景名，例如函数计算 Serverless 应用压测，然后在场景配置页签，输入压测 API 名称，例如 demo，单击添加压测节点右侧的图标。在压测 URL 区域中输入上一小节复制保存的 Serverless 应用的访问域名。配置完成后，您可以单击调试 API，验证 API 接口配置是否符合预期。当调试的响应状态码为 200 时，表示该 API 可以正常访问。

05 开发者场景体验

目前，「通过性能测试 PTS 对 Serverless 应用进行性能压测」场景已经上线云启实验室。在提供相关的免费试用额度的同时，提供相关操作流程与模板，以便大家快速体验通过 FC 创建应用以及通过 PTS 进行压测。

传送门：developer.aliyun.com/adc/scenari…

相关链接：

[1] little's law

en.wikipedia.org/wiki/Little…

[2] 函数计算控制台

account.aliyun.com/login/login…

[3] PTS 控制台

account.aliyun.com/login/login…

[4] 查看 PTS 压测报告

help.aliyun.com/document_de…

点击此处立即体验