Google Cloud Functions Java 11（测试版）运行时 - 性能问题

我使用 Java 11（测试版）运行时创建了一个新的 Cloud Function 来处理静态站点的 HTML 表单提交。这是一个简单的 3 字段表单（姓名、电子邮件、消息）。不涉及文件上传。该函数主要做两件事：

1. 使用 BitBucket 创建拉取请求
2. 使用 SendGrid 向我发送电子邮件

注意：它还验证验证码，但我已禁用它进行测试。

该函数在我的本地计算机（基本型号 2019 Macbook Pro 13"）上运行大约需要 3 秒。我位于东南亚。部署到 Google Cloud us-central1 时，相同的函数大约需要 25 秒（慢 8 倍） 。我在生产中运行了几乎相同的代码，作为 GAE Java 8 运行时上的 Servlet 的一部分，也在美国中部地区运行了几年。大约需要 2-3 秒，包括 recaptcha 验证和发送电子邮件。我正在尝试将其移植到 Cloud Function，但即使没有 recapcha 验证，Cloud Function 的性能也会慢 10 倍左右。

为了进行比较，Cloud Function 在 256MB / 400GHz 实例上运行，而我的 GAE Java 8 运行时在 F1 (128MB / 600GHz) 实例上运行。该函数仅使用约 75MB 内存。该函数配置为接受未经身份验证的请求。

我注意到即使是基本的字符串连接，例如：String c = a + b;在云函数上花费了 100 毫秒。我对调用进行了计时，将大约 15 个字符串连接成一个字符串大约需要 1.5-2.0 秒。

此外，向 HTTPUrlConnection 输出流写入一条小消息（~ 1KB）并读取响应大约需要 10 秒（是的，秒）！

/* Writing < 1KB to output stream takes about 4-5 secs */
wr = new OutputStreamWriter(con.getOutputStream());
wr.write(encodedParams);
wr.flush();
wr.close();

/* Reading response also take about 4-5 secs */
String responseMessage = con.getResponseMessage();

同样，下面的 SendGrid 代码还需要 10 秒来发送电子邮件。在我的本地机器上大约需要 1 秒。

Email from = new Email(fromEmail, fromName);
Email to = new Email(toEmail, toName);
Email replyTo = new Email(replyToEmail, replyToName);
Content content = new Content("text/html", body);

Mail mail = new Mail(from, subject, to, content);
mail.setReplyTo(replyTo);
SendGrid sg = new SendGrid(SENDGRID_API_KEY);
Request sgRequest = new Request();
Response sgResponse = null;
try {
    sgRequest.setMethod(Method.POST);
    sgRequest.setEndpoint("mail/send");
    sgRequest.setBody(mail.build());
    sgResponse = sg.api(sgRequest);            
} catch (IOException ex) {
    throw ex;
}

云功能显然有问题。由于我的原始代码在 GAE Java 8 运行时上运行，因此我可以轻松地将其移植到 Cloud Function，只需进行一些小的更改。否则我会选择 NodeJS 运行时。在本地计算机上运行此函数时，我也没有看到任何性能问题。

有人可以帮助我解决性能缓慢的问题吗？

您所看到的几乎可以肯定是由于与创建新服务器实例来处理请求相关的“冷启动”成本造成的。这是所有类型的 Cloud Functions 都存在的问题，如文档 https://cloud.google.com/functions/docs/bestpractices/tips:

本文档中的一些建议主要围绕所谓的冷启动。函数是无状态的，执行环境往往从头开始初始化，这称为冷启动。冷启动可能需要大量时间才能完成。最佳实践是避免不必要的冷启动，并尽可能简化冷启动过程（例如，通过避免不必要的依赖性）。

我预计 JVM 语言的冷启动时间会更长，因为除了服务器实例本身之外，初始化 JVM 也需要花费大量时间。

除了上述建议之外，几乎没有什么办法可以有效缓解冷启动。努力保温功能 https://stackoverflow.com/questions/51782742/how-can-i-keep-google-cloud-functions-warm并不像你想象的那么有效。如果你想搜索的话，网上有很多关于这个的讨论。

请记住，Java 运行时也处于测试阶段，因此您可以期待未来的改进。其他运行时也发生了同样的事情。