性能比拼: Google Functions vs. AWS Lambda

本内容是对知名性能评测博主 Anton Putra Google Functions vs. AWS Lambda performance benchmark 内容的翻译与整理, 有适当删减, 相关指标和结论以原作为准

在本视频中，我们将进行 AWS Lambda 和 Google Cloud Functions 之间的基准测试。

最近，Google Cloud 推出了新一代的 Cloud Functions；他们称之为 gen 2。它实际上只是 Cloud Run 的一个包装器（wrapper），这带来了更多的困惑。例如，在上一代中，要允许对函数进行未经身份验证的访问，您需要将 Cloud Functions 调用者（Invoker）角色授予所有用户。由于 gen 2 是 Cloud Run 的包装器，现在要达到同样的效果，您需要将 Cloud Run 调用者角色授予 Cloud Functions。

在第一个基准测试中，为了建立一个基线，我们将创建一个返回 "hello world" 的简单函数，并使用其 URL 调用该函数 1000 次。

在第二个测试中，我们将根据所使用的云平台，从 S3 或 GS（Google Storage）存储桶下载一个大图片，然后将其大小调整为 400x400 像素，并将结果保存回存储桶。

然后，根据这些结果，我们将设计第三个基准测试。

在 AWS 中，您只能为 Lambda 函数分配内存。它会根据配置的内存量按比例分配 CPU 能力。例如，如果您需要 1 个 vCPU，您需要为函数提供 1769 MB 的内存。还有一些其他参数，但这些是最重要的。Google Cloud Functions 使用类似的比例。我们将为两个函数分配相同数量的内存，即 1GB，这大约相当于超过半个虚拟 CPU。

此外，Lambda 和 Cloud Functions 能根据负载多快地进行自动扩缩（autoscale），也将在本次测试中扮演重要角色。

您可以在 我的 GitHub 仓库 中找到这些函数的源代码以及用于重现此基准测试的 Terraform 代码。如果您运行 terraform apply，您将获得一些 URL，可用于测试您的函数。

为了运行基准测试，我们将使用 hey 工具。这是一个小型的 Golang 应用程序，可以向 Web 应用程序发送一些负载。

首先，让我们测试 AWS Lambda 的 "hello world" 函数。我们需要向 hey 提供几个参数。首先，我们想要执行 1000 次请求。然后，我们希望启动 5 个工作线程（workers）来并行运行一些请求。还需要指定 GET 方法，并提供要调用的函数的 URL。它在运行时没有任何输出。

在结果中，您可以找到有关最慢请求、最快请求和平均请求时间的信息，以及许多其他内容。还有它每秒处理了多少请求。您还会得到一个带有响应分布的直方图。在这里，例如，请求的平均时间是 119 毫秒。同时，查看延迟分布也很重要，特别是完成所有请求的 95% 和 99% 所需的时间。为简单起见，我将只比较平均时间。

接下来，让我们运行完全相同的 "hello world" Google Cloud Function。结果稍微好一些。平均时间仅为 110 毫秒，大约快了 8%。并且我们得到了每秒 44 个请求，而不是 Lambda 的 41 个。

我认为您不应该过度依赖这些特定的基准测试结果，除了我们证明了我们的无服务器函数是正常工作的。我们还可以看一下并发执行情况；这显示了为处理流量创建了多少个函数实例。在 AWS 中，当您运行短期测试时，指标不是很准确，但我们仍然可以看到 Lambda 从 1 个实例扩展到了 3 个。GCP 在 "hello world" 测试中也启动了 3 个 Cloud Functions 实例。

现在让我们看一下另一个用于调整图像大小的函数。我们有 3 个 Golang 函数：getImage 用于从存储桶下载对象，uploadImage 用于将新的缩小后的图像保存到存储桶，以及 scaleImage 用于调整图像大小。在 GCP 中，我们使用 Google Cloud SDK，所以代码会略有不同，但逻辑相同。

要测试调整图像大小的 AWS Lambda 函数，获取其 URL 并使用相同的负载测试工具。这个测试大约需要 8 到 10 分钟才能完成。结果显示，平均持续时间为 2.38 秒，每秒处理 2 个请求。95% 的请求在 2.8 秒内完成。

现在运行相同的测试，使用 Google Cloud Function 来调整图像大小。结果明显慢很多。平均持续时间超过 3 秒，并且我们每秒仅完成了 1.5 个请求，这比 AWS 慢了 36%。

在这个基准测试期间，AWS 创建了 5 个用于调整图像大小的 Lambda 函数实例。另一方面，Google 将其数量翻倍，达到了近 10 个函数实例。

让我们运行最后一个测试，在这个测试中，我们将使用 AWS Lambda，但不是使用 S3，而是从 Google Storage 存储桶下载图像，调整大小并上传回去。基本上，就是 Google Cloud Function 所做的同样的事情。要授予权限，您需要获取凭据文件，将其放入您的 Lambda 函数中，并使用环境变量。

结果有点令人惊讶；AWS Lambda 的平均持续时间是 2.47 秒，这仍然比原生的 Google Cloud Function 快 31%。

总而言之，AWS Lambda 比 Google Cloud Function 快得多。在我看来，原因可能是分配给函数的 CPU 数量和质量。根据官方数据，在 AWS 中，您可以通过 1769 MB 内存获得 1 个 vCPU，而在 GCP 中，您需要 2048MB 才能获得 1 个 vCPU。还有其他可能影响函数性能的参数，例如网络和自动扩缩能力。

请在评论中告诉我您认为 Cloud Functions 较慢的原因。

感谢您的观看；可以看看另一个在 Golang 和 Rust 编写的 AWS Lambda 之间的基准测试；您会对结果感到惊讶。