FaaS函数运行时性能测试（1）冷启动时间

7.3 FaaS函数运行时性能测试

对FaaS运行时来说，比较关键的性能指标是冷启动时间（cold-start time）和自动扩缩容效率（auto-scaler efficiency）。

7.3.1 冷启动时间

当函数扩展时，每个函数实例服务的第一个请求都会受到加载和初始化代码所花费的时间的影响。如果初始化代码花费很长时间，则对平均延迟和百分位数延迟的影响可能会很大。

本节实验比较了单个请求下的冷启动时间和一段时间持续负载下的冷启动时间。实验中使用的基准函数bcrypt，如图7.1所示。

图7.1  冷启动时间测试使用的基准Serverless函数

bcrypt是一个密码散列函数，随着时间的推移，迭代计数增加会使其变慢，即使计算能力增强，它仍然可以抵抗暴力搜索攻击。该Serverless函数使用golang-http-armhf模板编写实现，用于处理客户端请求，并将该函数采用上文4.3.2中的实现方式设置为在闲置时自动缩容到零。对基准函数的资源限制为100MHz CPU和50MB内存，基准函数打包后镜像大小为33.4MB。

实验使用httpstat工具进行分析，生成HTTP请求的可视化分类，如图7.2所示，第一次函数调用基准Serverless函数需要2585ms，其中约99%用于服务器处理，包括了函数预热的冷启动时间和第一次函数处理的时间，主要部分是函数预热，另外约1%用于DNS查询。

图7.2  httpstat第一次调用分析

如图7.3所示，第一次调用后立即第二次调用相同的Serverless基准函数大约节省了94％的时间。随机输入字符串，bcrypt多次执行计算的服务端平均的处理时间约为289ms，说明该基准函数比较耗CPU时间，面对负载测试也比较敏感。

图7.3  httpstat第二次调用分析

为了对比，选用AWS Lambda云FaaS产品进行比对，采用其Go 1.x运行时，Zip代码打包，实现相同的基准测试函数bcrypt，其测试结果见表7.8。将AWS Lambda的预留并发（Reserved concurrency）设置为0，调用显示Rate Exceeded，必须设置一定数量的预留并发。此本节实验中，将预留并发设置为1。

表7.8  AWS Lambda调用基准函数测试

次数	DNS Lookup	TCP Connection	TLS Handshake	Server Processing	Content Transfer	Total
1	253ms	65ms	1192ms	1657ms	7ms	3174ms
2	61ms	62ms	824ms	1271ms	0ms	2218ms

本文边缘计算平台FaaS函数运行时的预热时间较长，因为实现中冷启动经过了加载、初始化、从0个副本扩容到1个副本的函数预热过程，而AWS Lambda预留采取了预留函数副本的方式。

从两者第一次调用服务端处理时间看，AWS Lambda的Serverless函数初始化速度很快。其他方面，涉及代码打包方式、FaaS技术实现细节、平台复杂度等诸多因素不便比较。相比之下，本文平台实现的FaaS函数运行时在冷启动速度上还有待提高。除此以外，我们可以直观看到边缘端FaaS相较云FaaS明显的时延优势。