Google函数Java 11 (Beta)运行时-性能问题

Question

我使用Java 11 (Beta)运行时创建了一个新的云函数来处理我的静态站点的HTML表单提交。这是一个简单的3字段形式(姓名，电子邮件，信息)。不涉及文件上传。该函数主要做两件事：

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

注意:它也验证了recaptcha，但我已经禁用它以进行测试。

在我的本地机器(基本型号2019 Macbook Pro 13")上运行时，功能大约需要3秒。我的总部设在东南亚。部署到Google Cloud US时，相同的功能需要大约25秒(8倍的速度)。我在生产中运行的代码几乎相同，作为GAE Java 8运行时的Servlet的一部分，在美国中部地区也是如此。它需要2到3秒的时间，包括recaptcha验证和发送电子邮件。我试图将其移植到Cloud功能，但即使没有recaptcha验证，云功能的性能也要慢10倍。

相比之下，云函数运行在256 my /400 GAE实例上，而我的GAE 8运行时运行在F1 (128 my/600 GAE)实例上。该函数只使用大约75 of的内存。函数被配置为接受未经身份验证的请求。

我注意到，即使是基本的字符串连在一起，比如：String c = a + b;在云函数上也有一个很好的100 on。我已经对调用进行了计时，一个简单的字符串连接到一个字符串中大约需要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 8运行时上运行的，所以我很容易将它移植到Cloud函数，只需做一些小改动。否则，我将使用NodeJS运行时。在本地机器上运行此函数时，我也没有看到任何性能问题。

有人能帮我理解慢性能的问题吗？

Answer 1

您所看到的几乎可以肯定是因为创建一个新的服务器实例来处理请求所带来的“冷启动”成本。这是与所有类型的云函数有关的问题，如文档中所述

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

除了服务器实例本身之外，我还希望JVM语言有更长的冷启动时间，因为将JVM初始化所需的时间很长。

除了上面的建议，没有什么可以有效地缓解冷启动。保持功能温暖的工作并不像您想象的那样有效。如果你想搜索的话，互联网上有很多关于这个的讨论。

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