无服务平台性能比较

大多数主要的云服务供应商都有可以提供功能即服务（FaaS）的无服务平台。最近一些基准测评研究了它们之间在运行时间、冷启动时间、依赖性和资源分配方面的性能区别。

Bernd Strehl 测评了无服务供应商AWS Lambda、Google Cloud Functions、Azure Functions 和IBM Cloud Functions 之间的性能区别。这些测评使用了Node.js 功能，尽管展示了不同供应商对请求负载响应的差异，但是这种测试方法所使用的样本太少，而却没有考虑到其他的一些因素，比如底层实例类型，因此受到了质疑。其他团队的测评用了不同的方法。

无服务供应商不仅要考虑CPU、内存和请求数量，还要考虑网络和存储。不同供应商对于如何根据特定的CPU 需求来调整内存都存在差异，例如，AWS 给配备较高内存的实例提供更多的CPU 周期。Google 也采用了类似的策略，而Azure 对于CPU 分配的策略则不同，“4-vCPU 的虚拟机将分配更多CPU”。

并发请求改变了功能的平均响应时间。对于非并发请求，几乎所有的供应商资源分配都相同，除了Google 大约有30% 左右的偏差。对于并发请求，当同时执行50 个相同的调用，AWS 的计算时间增加了46%，Google 和Azure 分别为7% 和3%，IBM 为154%。其他的测评表明，AWS 在并发处理方面有最好的性能表现。

冷启动时间是无服务功能在一段时间没有使用后响应第一个请求所需要的时间。研究结果表明，要维持性能不变对所有的供应商来说都是一个挑战。云供应商一般会不间断地运行一组一般性的worker（即worker pool）。第一个进站的请求获得其中一个实例，该实例负责处理这个请求。实例在处理完第一个请求后保持运行状态。不过，保持运行的时间长短因供应商不同而不同。 M ikhail Shilkov 在他的一篇文章中说明了Azure 的冷启动时间是20 分钟，而Google Cloud Functions 时间则不定。AWS 官方宣布的时间是5 分钟，但实际时间更长，因为他们的工程团队进行了调整。当服务需要横向扩展，需要加入新的服务实例时也会发生冷启动。

运行时的选择也会影响性能。Node.js 应用程序不需要启动很多CPU，而.NET Core 运行时需要更多内存（在AWS Lambda 中）。冷启动时间随着分配的内存的增加而减少。测评表明，对于Javascript 而言，AWS 的冷启动时间最快，之后是GCP 和Azure。

查看英文原文： Serverless Platforms Compared for Performance

感谢无明对本文的审校。