Firebase 功能、冷启动和缓慢响应

Question

我正在使用 Firebase 托管和 firebase 功能开发一个新的 React 网站。

我在 GCP Cloud Sql 和 GCP Secret Manager 中使用 MySQL 数据库（大量数据报告需要 SQL）来存放数据库用户名/密码。

Firebase 函数用于从数据库中提取数据并将结果发送回 React 应用。

在我的本地模拟器中，一切正常且响应迅速。 当它部署到 Firebase 时，我注意到对函数的第一个请求，有时是第二个请求大约需要 6 秒才能响应。之后，他们的反应不到 1 秒。对于我可以在日志中看到的缓慢响应，数据库池已初始化。 因此，缓慢的响应是实例的第一个打击。我假设在我的情况下正在创建两个实例。 请注意，无论是第一次调用还是第二次调用，不需要数据库的函数都会快速响应。

大约 15 分钟未使用服务后，我遇到了同样的问题。我假设正在回收实例并正在创建一个新实例。

问题是每个函数都有自己独立的数据库池，因此每个函数最初都会提供缓慢的响应（可能第二次调用两次）。 该网站将看到低流量，这意味着大多数用户会遇到这种缓慢的响应。

通过删除对 Secret Manager 的引用并对用户名/密码进行硬编码，响应时间已降至 3 秒以内。但这仍然是不可接受的。

有没有办法：

1. 增加函数如果不使用则回收的时间？
2. 标记不应回收的实例？
3. 有没有办法创建一个在循环之间不会关闭的全局数据库池？
4. 是否有一种方法可以在 Firebase Functions 中使用数据库连接以避免重新初始化数据库池？
5. 这是函数的本质吗？我仅限于这种行为吗？

由于我处于早期开发阶段，迁移到 AppEngine/Node.js（灵活计划）能否解决回收问题？

Answer 1

首先，您遇到的第一个和第二个请求花费时间最长的问题称为cold starts。

这完全是有道理的，因为新的实例被启动了。在以下情况下，您可能会出现冷启动：

1. 您的函数已部署但尚未触发。
2. 您的函数已足够空闲（未处理请求），已被回收用于资源。
3. 您的函数会自动扩展以处理容量和创建新实例。

我了解到您提出的五个问题旨在解决 Cloud Functions 回收实例的问题。

问题 1 到 4 的直接答案是 No，因为 Cloud Functions 实现了 serverless paradigm。

这意味着一个函数调用不应依赖于先前调用设置的内存状态（数据库池）。

现在这并不意味着您不能改善冷启动启动时间。

通常，冷启动启动时间的第一贡献者是依赖项的数量。

来自 Google Cloud 技术频道的 video 准确地解决了您遇到的问题，并更详细地描述了为调整 Cloud Functions 所实施的做法。

如果在完成视频中的最佳实践后，您的冷启动显示不可接受的值，那么，正如您已经建议的那样，您需要使用一种产品，该产品允许您像 App Engine Standard 一样启动 minimum set of instances .

您可以通过稍后实施warm up requests. 来进一步提高 App Engine 标准实例的就绪性

预热请求会在任何实时请求到达该实例之前将您的应用代码加载到新实例中。最后一个文档讨论了加载请求，这类似于冷启动，即您的应用程序代码被加载到新创建的实例的时间。

我希望你觉得这很有用。